Hi, I just foold around with xorg-server[-suid] to solve an xpra issue (bug 448588) unable to `cp /usr/bin/Xorg` as non-root w/o user intervention (see elog). But I was unable to start the server as non-root, first with an old Xorg.0.log with > Fatal server error: > Cannot move old log file "/var/log/Xorg.0.log" to "/var/log/Xorg.0.log.old" followed by an > Fatal server error: > Cannot open log file "/var/log/Xorg.0.log" I see the point that most xorg-server instances might be started by gdm/whatevder* as root, providing the login manager and then exec(3)'ing into the actual user session. But I thought the fuzz about USE -suid was to take atvantage from KVM kernel stuff and be able to run Xorg as non-root process. What's your opinion about that? p.s. I've no idea what upstreams proposed solution for the privilege mess might be, but something like an per-user directory of logs inside an sticky, world-writeable /var/log/Xorg might suffice /(/var/log/Xorg/$user/Xorg.0.log).
Created attachment 334504 [details] Xorg.0.log on nvidia error on an nvidia system after setting `chmod a+w /var/log` (for testing only).
As you correctly say, xorg-server[-suid] is perfectly usable if you start X through /etc/init.d/xdm or as root. Also as non-root it can be started if you use xf86-video-dummy and no input devices (which is the plan for bug 409925). What is currently not documented is how to start X with access to input and display hardware as non-root. The suid flag will remain enabled by default until it is. We are currently lacking a volunteer who enumerates all the possible cases and collects the available information which is scattered around wikis, bugzillas (e.g. bug 419485 comment 6), forums and mailing lists.
I pushed 1.19.5-r1 which now has a suid-wrapper USE flag. I think the suid USE flag is pretty useless now, and should likely be removed. It would be great to get some confirmation.
(In reply to Matt Turner from comment #3) > I pushed 1.19.5-r1 which now has a suid-wrapper USE flag. Nope, no such USE flag. The ebuild does specify --enable-suid-wrapper unconditionally, but it doesn't work: startx as regular user no longer works. There doesn't seem to be any "suid wrapper" installed either; at least I couldn't find any. I had to revert to 1.19.5+suid to get a working desktop.
(In reply to Holger Hoffstätte from comment #4) > (In reply to Matt Turner from comment #3) > > I pushed 1.19.5-r1 which now has a suid-wrapper USE flag. > > There doesn't seem to be any "suid wrapper" installed either; > at least I couldn't find any. The wrapper is in ‘/usr/libexec/Xorg.wrap’, manuals are Xorg.wrap(1) and Xwrapper.config(5). > I had to revert to 1.19.5+suid to get a working desktop. Same here, so I can confirm with +suid-wrapper, startx doesn‘t work. I set: allowed_users = anybody needs_root_rights = yes in ‘/etc/X11/Xwrapper.config’ without luck. While testing I always ended up with some kind of “Permission denied”: - “Unable to retrieve master” ... “(EE) AddScreen/ScreenInit failed for driver 0” or with - “xf86OpenConsole: Cannot open virtual console 7 (Permission denied)” A `strace -e trace=open,ioctl Xorg 2>&1 | view -` discover a Permission denied for ‘DRM_IOCTL_SET_MASTER’. I gave up for now and revert also to 1.19.5+suid.
Right. We dropped suid and suid-wrapper shortly after adding suid-wrapper, since I cannot see a compelling reason to offer such flexibility. You should have % ls -lh /usr/libexec/Xorg* -rwxr-xr-x 1 root root 2.2M Oct 20 20:27 /usr/libexec/Xorg -rws--x--x 1 root root 11K Oct 20 20:27 /usr/libexec/Xorg.wrap where Xorg.wrap is the suid wrapper. /usr/bin/Xorg is now a shell script that chooses which to execute. I'm not sure what problem you're having. Please open a new bug. This one should be resolved, since there is no configuration to document :)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7e9f7ca88eeeb4be5c5bfaa4f73cc3ba5c211947 commit 7e9f7ca88eeeb4be5c5bfaa4f73cc3ba5c211947 Author: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> AuthorDate: 2017-10-23 19:40:12 +0000 Commit: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> CommitDate: 2017-10-23 19:40:12 +0000 profiles/package.mask: mask >=x11-base/xorg-server-1.19.5-r1 Dropping suid breaks some use cases. Bug: https://bugs.gentoo.org/show_bug.cgi?id=450364 Bug: https://bugs.gentoo.org/show_bug.cgi?id=635102 profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)}
I'm not sure what's the consensus here but I wanted to point out that Arch builds xorg-server with --enable-suid-wrapper --disable-install-setuid and this seems to be fine for them in both cases: * running as $USER with startx * running as root from a login manager.
Since the -suid is fully working now even without systemd due to elogind integration, do we still need to do anything here?
There's no much to be done here really. To run -suid you need to either: - use xdm that runs /usr/bin/Xorg as root anyway. - have *logind interface, like elogind or systemd, that grants you control master over DRM (for the KMS enabled drivers) -- meaning USE=elogind or USE=systemd on xorg-server. - Use driver that is not KMS (is there anything like that still in the tree?) so it does not require SETMASTER ioctl (CAP_SYS_ADMIN permissions required, so basically root) AND have access to input devices, like input system group membership (*logind grants input access, unless you run udev-less). Closing it, if you feel like it should be reopened -- feel free to do so.
