I was getting a permission denied on startx after installing x11-base/xorg-server-21.1.2-r3 # namei -l /usr/bin/X f: /usr/bin/X drwxr-xr-x root root / drwxr-xr-x root root usr drwxr-xr-x root root bin lrwxrwxrwx root root X -> Xorg -rws--x--x root root Xorg # file /usr/bin/Xorg /usr/bin/Xorg: setuid POSIX shell script, ASCII text executable I ran chmod g+r,o+r /usr/bin/Xorg with help from tirnanog on irc. He also states that > chmod 0755 would also have fixed it. the original mode was 2711. the "2" is pointless (for a script) and the "11" is flat out wrong as it stops non-root users from being able to run the script. I can duplicate the issue again by remerging x11-base/xorg-server-21.1.2-r3
Created attachment 760776 [details] emerge.info
Looks like a mistake with how USE are checked. USE="-elogind -systemd suid" would get you: $ file /usr/bin/Xorg /usr/bin/Xorg: setuid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 5.8.0, stripped So the permissions would be entirely fine. When throwing USE=elogind or systemd in the lot you get the suid wrapper instead, so the ebuild tries to avoid setting suid then: if ! use systemd || ! use elogind; then if use suid; then chmod u+s "${ED}"/usr/bin/Xorg fi fi ..but this first condition is always true, there's always at least one that's unset.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d3570528f161a3f1086b351137d88f46c6a138a commit 3d3570528f161a3f1086b351137d88f46c6a138a Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2022-01-01 21:48:43 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2022-01-01 21:51:01 +0000 x11-base/xorg-server: fix suid for installations without logind provider. Closes: https://bugs.gentoo.org/830251 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> .../{xorg-server-21.1.2-r3.ebuild => xorg-server-21.1.2-r4.ebuild} | 4 ++-- x11-base/xorg-server/xorg-server-9999.ebuild | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
It should now work in the way you'd think it will work. I'd like also to make a point, that if anyone by choice refuse to use logind provider and/or PAM, then you are en route to enormous amount of problems, there's no viable reason to go this route unless you want to boot Gentoo on system that runs out of NOR flash or other very limited hardware. And it comes from someone who from 2012 to January of 2020 were running with mdev and set of custom scripts instead of using udev. Stop enabling suid, start using logind provider, keep pam enabled.
More specifically this bug was causing issues for those /using/ a logind provider. It was due to the combination of logind+suid resulting in a shell script rather than the real binary.
This is not the case. The shell script is there because If there's logind provider, we opt for suid wrapper rather than actual suid on USE=suid. The problem is however that sh will drop suid and act as if it was not there. furthermore it was only adding the +s if logind provider was there, which does not make any sense, since suid wrapper is then used. But it was not adding the actual suid on binary when no logind provider is used. This fixes the case with '-elogind -systemd suid', the shell script (suid wrapper) remains for when logind provider is used.
(In reply to Piotr Karbowski from comment #6) > This fixes the case with '-elogind -systemd suid', the shell script (suid > wrapper) remains for when logind provider is used. But this wasn't broken? Considering this issue is about the shell script and these US wouldn't even install a shell script to get suid wrong on. That aside, the issue is still fixed but again this was broken for people using logind+suid not no-logind+suid.
The code had logic that if systemd or logind is unset (so always at least one, at most both are unset) and if suid is enabled, it will +s the Xorg. However when either elogind or systemd is enabled, as well as suid, build system installs suid_wrapper. The suid wrapper does not cover non-logind installations, so the additonal code was added. It had faulty logic, and it is now fixed. Regardless what bug is about, the result reported here was that shellscript (wrapper) had +s set, but it shouldn't since if wrapper exists, +s is not needed, and only needed if it's plain binary without logind interface.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5e10481bfe4fc97c7b5a5352c6b870e9e6edcc21 commit 5e10481bfe4fc97c7b5a5352c6b870e9e6edcc21 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2022-01-03 00:53:20 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2022-01-03 00:53:23 +0000 x11-base/xorg-server: Forward port fix for bug #830251 My version bump was done on a git tree without this fix. Closes: https://bugs.gentoo.org/830251 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-base/xorg-server/xorg-server-21.1.3.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
