| Summary: | x11-base/xorg-server-1.20.3:0/1.20.3 without systemd : "parse_vt_settings: Cannot open /dev/tty0 (Permission denied)" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Manfred Knick <Manfred.Knick> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | anton.kochkov, balint, gentoo, kajanos, leho, nanikata15, ostroffjh, paxanbi4, simon.vanderveldt+gentoo, slashbeast, stefan.kuhn.zurich, zerochaos |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | amdgpi, no-suid Xsorg | ||
|
Description
Manfred Knick
2018-11-03 18:22:22 UTC
Does the patch in https://bugs.gentoo.org/669648#c31 fix this for you? (In reply to Matt Turner from comment #1) > Does the patch in https://bugs.gentoo.org/669648#c31 fix this for you? Unfortunately not. WORKAROUND: Explicitly restore USE += suid @ Matt Whitlock , @ Laszlo Valko : (In reply to Matt Whitlock from Bug 669648 comment_#37) [https://bugs.gentoo.org/669648#c37] > I don't know Gentoo's official policy ... > ... The people with unusual configurations ... <--- ??? !!! What the hell should be *unusual* by using basic elementary KISS OpenRC | startx | twm ? Perhaps you might consider sometimes reading " Linus Torvalds: WE DO NOT BREAK USERSPACE! " [https://lkml.org/lkml/2012/12/23/75] and [https://felipec.wordpress.com/2013/10/07/the-linux-way/]. Having set up a productive environment for a customer being completely wrecked by a regular update without any warning and declaring that as "for the better good of all others" is outright *unacceptable*. In case my understanding got you wrong, I apologize in advance, but ask to clarify. Following "Non root Xorg" in [https://wiki.gentoo.org/wiki/Non_root_Xorg], startx -- vt1 basically works, but X11 settings from /etc/X11/xorg.conf.d/ are either ignored or screwed-up: - left-handed-mouse - keyboard settings Falling back to WORKAROUND. From comment #2, I would like to emphasize > ... without any warning ... (In reply to Manfred Knick from comment #3) > but X11 settings from /etc/X11/xorg.conf.d/ > are either ignored or screwed-up: WORKAROUND: cat /etc/X11/xorg.conf.d/ >> /etc/X11/xorg.conf ==> /etc/X11/xorg.conf.d/ does not get evaluated Removing xorg.conf.d completely, only keeping the aggregated xorg.conf,
starting X, xorg.conf.d gets re-created and 20opengl.conf in it.
USE += doc:
man xorg.conf still documents
"
Additional configuration files are searched for in the following directories
when the server is started as a normal user:
...
/etc/X11/xorg.conf.d
...
"
--
https://lists.x.org/archives/xorg-announce/2018-May/002893.html
https://lists.x.org/archives/xorg-announce/2018-October/002928.html
https://xorg-devel.x.narkive.com/VPAbz5O6/patch-xserver-meson-set-xconfigfile-to-xorg-conf-instead-of-etc-xorg-conf
confirming bug, just did a quick update, reboot and... cannot start X again no systemd here ...help?!? actually, I'm not so sure anymore it is really xorg-server-1.20.3 I installed that on another machine (also no systemd) on Oct 26 already and it works fine it is maybe another X related package update from today or yesterday, there were several: libX11-1.6.7, libSM-1.2.3, libdrm-2.4.96, mesa-18.2.4, .... Confirm, any update how to solve the problem ? (In reply to Michal Jakubowski from comment #8) > Confirm, any update how to solve the problem ? Confirm, working with suid flag. Also for me, working with USE += suid I just ran into this issue as well on one of my machines, wasted two hours on it for nothing. Whilst I appreciate the effort everyone is putting into the distro these things really shouldn't happen. At the very least a news item should've been (and still should be!) posted to inform the users of this breaking change. Addressed the issue for now using USE +=suid so it's at least working again. Is there an actual suggestion for how to properly fix this problem? Otherwise it probably makes more sense to revert this change or at the very least default to +suid. Setting USE += suid is defenitely the wrong (backward oriented) direction. Please, do c.f. [https://wiki.gentoo.org/wiki/Non_root_Xorg] ! , and hints in comments 3 and 4. CONFIRMATION: WORKSFORME *without* suid, stable. (In reply to Manfred Knick from comment #12) > Setting USE += suid is defenitely the wrong (backward oriented) direction. Why? It works fine I think the plan here is to leave IUSE=suid and default to off, but to setgid the Xorg binary to the input group. That should give 95%+ of people a working configuration with suid off. The remaining people would be using user modesetting drivers. (In reply to Simon from comment #13) > Why? It works fine Search for "Xorg setuid security vulnerability". Expect Matt Turner, Matt Whitlock, Laszlo Valko et al. definitely not working for wasting excess of time ... BTW: Thanks! (In reply to Matt Turner from comment #14) Perhaps sprinkle with a pinch of salt by adding an "ewarn ... -suid ..." providing reference to "Non root Xorg", and within there, hint rationale about security concerns? (In reply to Manfred Knick from comment #3) > but X11 settings from /etc/X11/xorg.conf.d/ > are either ignored ... Separated into Bug 670796 - x11-base/xorg-server-1.20.3 without systemd, starting via startx: xorg.conf.d ignored CONFIRMATION: Working stable in a multi-monitor-setup (2x2) since 2018-11-04. In retrospect, xorg.conf.d not being evaluated had the consequences described in comment #3, including Driver "nvidia" Option "XkbLayout" "de" Option "ButtonMapping" "3 2 1 4 5" # left-handed (In reply to Manfred Knick from comment #15) > (In reply to Simon from comment #13) > > Why? It works fine > Search for "Xorg setuid security vulnerability". > > Expect Matt Turner, Matt Whitlock, Laszlo Valko et al. > definitely not working for wasting excess of time ... I can't tell if you're being rude or not. If so, make it more apparent so I understand. (In reply to Matt Turner from comment #16) Hi, Matt, the adresseé indicated was: > > (In reply to Simon from comment #13) <----- Already in first line of comment #0, I gave reference to the (bug) story why you guys introduced -suid, as well as evidence how to solve the current problem in comments #1 - #4. Instead of "#_Mee_Too", "help?!?", and finally security-ignorant "Why? It works fine" I would have expected people from comments #6 ff. to *read*. This ensnared me to a pinch of irony to them as well as my explicit "BTW: Thanks!" for you guys working fingers to the bone and the results achieved. I was not aware this could possibly be misunderstood. Kind regards Yours respectfully Manfred Can we get +suid if -systemd? or the at_least_one_of(suid systemd)? So users does not emerge 'broken' xorg. I've also tried to go with -suid, being part of input group and doing `startx -- vt1` and it does not work on amdgpu (opensource) driver. 'AddScreen/ScreenInit failed'. Regardless if it's the good or not to have suid, as current way will not work for everyone, how about restoring the old suid-enabled-by-default way, and then finding a way to run without root on non-systemd systems? This kind of change is worth at least a news item. I also tried it now on another system, with Intel Skylake gpu, that defaults to modesetting driver. I am getting 'drmSetMaster: Permission Denied' even if I go ahead and do something like `chown -R piotr /dev` just to check if there's anything else there beside input that I would need access to. It does not work. `strace -f` shows that's it's permission denied from ioctl() call. The linked Non_root_X guide is far from enough. Be so kind and restore +suid or one_of(suid systemd). Integration with elogind does not seems to fix things for me. I've deployed elogind, and confirmed that elogind works. Upon login, it does print that seat0 is taken by my user, and now /dev/tty1 is owned by my user, however the same outcome whatever I use `startx -- vt1` or just `startx`. Failure on AddScreen/ScreenInit. This testing was done on amdgpu system, with RX580 card. (In reply to Piotr Karbowski from comment #21) For differential analysis: - Have you tested with simple plain twm already? E.g. login and 'startx /usr/bin/twm -- vt1' ? - Could you be so kind to disclose which WM | DM you are using? Perhaps the exact full command line? - Perhaps attach your xorg.conf for comparison? - eselect opengl list ? AFAICS, non-kms drivers have been the problem, not kms drivers. -- https://bugs.gentoo.org/635102#c24 --> https://src.fedoraproject.org/rpms/xorg-x11-server/blob/master/f/0001-Fedora-hack-Make-the-suid-root-wrapper-always-start-.patch --> https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights It's not connected to my window manager. I run openbox, no xorg.conf, just xorg.conf.d with setting to use legacy mouse and keyboard driver. I have no udev running and xorg-server has been built without support for it. This is as much plain setup as one can have. elogind install quite a few udev rules, perhaps udev control permissions in /sys too, I will resume more testing tomorrow. Maybe I will disable mdev and try it now with eudev+elogind combo. (In reply to Piotr Karbowski from comment #23) Did you read my comments #3 and #4 above ? I did. Merging xorg.conf.d into xorg.conf changes nothing. It's still unable to retrive drm master. So i've enabled eudev togther with elogind, I've rebooted, confirmed that all kind of fancy permissons were added around /dev, like Posix ACL on /dev/dri/card0 and so on, The same problem. 'AddScreen/ScreenInit' failure and 'Unable to retrieve master'. I've googled around and come across this https://archives.gentoo.org/gentoo-user/message/65d718009941406b04e40435c11154f1 Perhaps elogind+eudev still cannot replace systemd in this regard. I am out of ideas, it appears that the suid on Xorg is needed at least for amdgpu and ati driver users. (both opensource) It seems like Xorg has a hard dependency on systemd/logind to switch to server-managed fds. See https://github.com/mirror/xserver/blob/master/hw/xfree86/os-support/linux/lnx_platform.c#L42 and search for server_fd in that file. And see https://hansdegoede.livejournal.com/14268.html under the "driver changes" header. I don't know how equal elogind is compared to systemd's logind. Does systemd still have it's own logind/doesn't it use elogind? (In reply to Piotr Karbowski from comment #26) COURTESY: - installing x11-wm/openbox-3.6.1-r1:3 - 'startx /usr/bin/openbox -- vt1' Confirmation: - works instantaneously - mouse runs across all four screens - I can start e.g. kate from the openbox menu - keyboard works - 'logout' option works shutting down openbox properly WORKSFORME even with a quad-monitor-setup. In the information supplied, Senior (X11) Developer Hans de Goede had clearly indicated that "most display managers are not ready yet to start Xorg in way which will keep it working without root-rights". So please, finally, do test with - plain user login - plain /etc/X11/xorg.conf | no xorg.conf.d - plain 'startx /usr/bin/twm -- vt1' first. If that still does not work, please finally do disclose *complete* information of your setup / start <--! as well as *complete* log files as attachments. <--! @ Simon: Thanks for your digging! Manfred Knick, as I stated above. I tested it without xorg.conf.d, with merged xorg.conf and without any of this. My X config files are limited to keyboard driver and mouse anyway, to setup keymap, nothing beside that. Trying to start anything else than openbox is not worth even checking, because the X does not start. The screen does not goes black, it stays on tty1, does not even flicker, and print information about being unable to set master, after that xinit just drops information about being unable to reach Xserver and exists. Instead of 'startx' or 'startx -- vt1' I can just run 'X' or 'Xorg' and get the same error, unable to set master. The moment I run `chmod +s /usr/bin/Xorg` it starts to work. Even if I chown everything in /dev and /sys to my local user, it still does not work, and if I run Xorg via strace, it gets permission denied on ioctl(). I've already posted about this above. Created attachment 554830 [details]
amdgpi, no-suid Xsorg
Manfred Knick, Xorg.0.log attached, can you please, finally, reread all my comments here? Thanks. On the 2nd system, skylake intel iGPU that defaults to modesettings driver I am unable to start X without suid either.
But this time, on intel, it give me the flat Permission Denied on ioctl():
[pid 6130] ioctl(9, DRM_IOCTL_SET_MASTER, 0) = -1 EACCES (Permission denied)
I even tried to without suid, but still et X ignore permissions on filesystem by setting the capability
setcap cap_dac_override+ep /usr/bin/Xorg
But the result was the same. Permission denied on setting master, unlike on amdgpu, where I got unable to retrive master.
However, if I set CAP_SYS_ADMIN, which by all means is only a little bit better than suid, X start as normal user.
chmod -s /usr/bin/Xorg
setcap cap_dac_override,cap_dac_read_search,cap_sys_admin+ep /usr/bin/Xorg
This means that having rw access (via input group) to inputs, and access to dri/drm via video group is not enough to run rootless, there's another thing about setting drm master that is missing here.
Revisiting Simon's comment and looking into hw/xfree86/drivers/modesetting/driver.c I noticed a snippet:
1517 SetMaster(ScrnInfoPtr pScrn)
1518 {
1519 modesettingPtr ms = modesettingPTR(pScrn);
1520 int ret;
1521
1522 #ifdef XF86_PDEV_SERVER_FD
1523 if (ms->pEnt->location.type == BUS_PLATFORM &&
1524 (ms->pEnt->location.id.plat->flags & XF86_PDEV_SERVER_FD))
1525 return TRUE;
1526 #endif
1527
1528 if (ms->fd_passed)
1529 return TRUE;
1530
1531 ret = drmSetMaster(ms->fd);
1532 if (ret)
1533 xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "drmSetMaster failed: %s\n",
1534 strerror(errno));
1535
1536 return ret == 0;
1537 }
so I am hitting the case where Xorg did not got a descriptor, so it continue to do it's thing and fails hard. Anyone of you actually got that working with elogind?
FWIW the same caps, to ignore filesystem ownership (input) with CAP_SYS_ADMIN let me start the X on AMDGPU box too, both with `startx` which defaults to tty7, as well as `startx -- vt1` to use tty1. https://stackoverflow.com/questions/29708596/drmdropmaster-requires-root-privileges In that case, it appears that you need to run elogind(+eudev) to be able to run X without root. Although it does not work here with elogind and eudev for some reason, it does suggest that you need a root-privileged process do poke the framebuffer anyway, to set the master. In this case, if there's -suid, xorg-server should depend on either systemd or elogind, otherwise it won't work. Since I cannot get elogind working here on 2 separated boxes, can someone invest time into testing it and finding the solution? (In reply to Piotr Karbowski from comment #35) > https://stackoverflow.com/questions/29708596/drmdropmaster-requires-root- > privileges > > In that case, it appears that you need to run elogind(+eudev) to be able to > run X without root. Although it does not work here with elogind and eudev > for some reason, it does suggest that you need a root-privileged process do > poke the framebuffer anyway, to set the master. > > In this case, if there's -suid, xorg-server should depend on either systemd > or elogind, otherwise it won't work. > > Since I cannot get elogind working here on 2 separated boxes, can someone > invest time into testing it and finding the solution? Thank you for all your analysis and attempts to make this work. Given this, I believe you are right, we should set the default to +suid. I will make that change. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4928f93b1f033b51d8f1e80cc4730da64bf318ca commit 4928f93b1f033b51d8f1e80cc4730da64bf318ca Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2018-11-11 17:43:00 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2018-11-11 17:44:16 +0000 x11-base/xorg-server: Enable suid by default Closes: https://bugs.gentoo.org/670212 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-base/xorg-server/xorg-server-1.20.3.ebuild | 2 +- x11-base/xorg-server/xorg-server-9999.ebuild | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (In reply to Piotr Karbowski from comment #29) > ... the X does not start. The screen does not goes black, it stays on > tty1, does not even flicker, and print information about being unable to set > master ... Thanks for this description. The primary error in your attached log (comment #31) "Unable to retrieve master" results from x11-drivers > xf86-video-ati > src/radeon_kms.c : " static Bool radeon_set_drm_master(ScrnInfoPtr pScrn) : <--- ... err = drmSetMaster(pRADEONEnt->fd); if (err) ErrorF("Unable to retrieve master\n"); <--- Line 2114 ... " xorg-server "only" fails in consequence: x11-base > xorg-server > hw/xfree86/common/xf86Init.c , Line 745 : " else { /* This shouldn't normally happen */ FatalError("AddScreen/ScreenInit failed for driver %d\n", i); } " I know this has been closed with simply defaulting to enabling suid. But when I read through the comments, I guess the better resolution for people without systemd would be to add elogind support to xorg-server. Please see: https://bugs.gentoo.org/670930 and https://github.com/elogind/elogind/issues/70#issuecomment-438832595 ff RE: But when I read through the comments https://writingservice.essayhave.com, I guess the better resolution for people without systemd would be to add elogind support to xorg-server. Thank you very much for your help and effort! 👍 It is there already thought, I ran openrc+elogind and ran xorg-server without root. Please refer to https://wiki.gentoo.org/wiki/Non_root_Xorg |
