Since commit bdd4b3309fef4c58066f9a5f88b4db448be19dfe: """ commit bdd4b3309fef4c58066f9a5f88b4db448be19dfe Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2019-03-21 19:39:09 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2019-03-21 19:39:09 +0000 x11-base/xorg-server: elogind integration, -suid by default. This enables users that does not run systemd to have suid-less Xorg. A privileged entity is required for SETMASTER and DROPMASTER calls to get control over framebuffer. Additionally elogind with udev grant user access to input device nodes and elogind alone interfaces the SETMASTER/DROPMASTER calls. Xorg-server will do keeptty automatically, meaning one does not need to pass any extra parameters to `startx` to get things working, It does take adventage of $XDG_SEAT and $XDG_VTNR set by pam_elogind upon login. Although it's possible to run rootless without udev (with any /dev manager, like mdev of busybox), the configure flag that USE=elogind enables (--enable-systemd-logind) checks if udev toggle is also enabled. This leads to a situation where udev needs to be present on user system while building, however, udev does not needs to be running, as long as user is in video and input system groups, elogind is running and user logged in when pam_elogind.so was enabled Xorg will start as regular user. Closes: https://bugs.gentoo.org/670930 """ Dependencies of x11-base/xorg-server contain: systemd? ( sys-apps/dbus sys-apps/systemd ) elogind? ( sys-apps/dbus sys-auth/elogind sys-auth/pambase[elogind] ) 1. Both sys-apps/systemd and sys-auth/elogind have "pam" USE flag which enables optional dependency on virtual/pam. 2. sys-auth/pambase has "elogind" and "systemd" USE flags which enable optional dependency on sys-auth/elogind[pam] and sys-apps/systemd[pam], respectively. In x11-base/xorg-server, dependency on sys-auth/pambase[elogind] is not strictly necessary. x11-base/xorg-server[elogind] should work in a system without PAM to the same degree as x11-base/xorg-server[systemd] would. I suggest implementation of one of the following solutions: 1. Dropping dependency on sys-auth/pambase[elogind] and relying on users setting consistent USE flags globally: systemd? ( sys-apps/dbus sys-apps/systemd ) elogind? ( sys-apps/dbus sys-auth/elogind ) 2. Adding "pam" USE flag to x11-base/xorg-server and making dependency on sys-auth/pambase optional on this USE flag and consistently present in both elogind and systemd blocks: systemd? ( sys-apps/dbus sys-apps/systemd pam? ( sys-auth/pambase[systemd] ) ) elogind? ( sys-apps/dbus sys-auth/elogind pam? ( sys-auth/pambase[elogind] ) ) Regardless of chosen solution, PAM should remain optional.
> Regardless of chosen solution, PAM should remain optional. I rather keep it as-is until desktop profiles switch to elogind. Then we can relax this dependency, although it's inconstant, it's this way to make it simpler for end users. The elogind have no use without pam, as without that, you have no seat assigned, and xorg-server cannot really use it then.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #0) > 2. Adding "pam" USE flag to x11-base/xorg-server and making dependency on > sys-auth/pambase optional on this USE flag and consistently present in both > elogind and systemd blocks: > systemd? ( > sys-apps/dbus > sys-apps/systemd > pam? ( sys-auth/pambase[systemd] ) > ) > elogind? ( > sys-apps/dbus > sys-auth/elogind > pam? ( sys-auth/pambase[elogind] ) > ) In this variant, dependency on sys-auth/pambase should be only in RDEPEND and can be simplified: CDEPEND (used for DEPEND and RDEPEND): systemd? ( sys-apps/dbus sys-apps/systemd ) elogind? ( sys-apps/dbus sys-auth/elogind ) RDEPEND: pam? ( sys-auth/pambase[elogind?,systemd?] )
Adding pam flag there creates artificial dependency. The xorg-server itself does not uses pam, however xorg-server will not be able to use elogind integration without pambase[elogind]. The dependency on pmabase[elogind] in case of +elogind however ensure that if you enabled +elogind on your xorg-server, you will also enable elogind as session manager. Unless you log in with elogind enabled, you will not get a seat, and if you do not get a logind seat, you will not be able to start Xserver if xorg-server was built with USE='elogind -suid'. Meaning, the USE=elogind on xorg-server have no purpose if you did not enabled elogind on pambase too. Once the elogind will go default in desktop profiles (as per https://bugs.gentoo.org/682160) I think we then could remove this pambase dependency, as it's just to ensure that *most* people end up with working elogind integration as for now.
(In reply to Piotr Karbowski from comment #3) > Unless you log in with elogind enabled, you will not get a > seat, and if you do not get a logind seat, you will not be able to start > Xserver if xorg-server was built with USE='elogind -suid'. You can manually specify seat in starx arguments, which are internally passed to /usr/bin/X. Example: $ startx -- -seat seat0 vt11 Maybe it is also necessary to firstly manually export XDG_SEAT and other environmental variables. Example: $ export XDG_SEAT="seat0" $ export XDG_VTNR="11" $ export XDG_SESSION_TYPE="x11" $ export XDG_SESSION_CLASS="user" $ export XDG_SESSION_DESKTOP="KDE" $ export XDG_SESSION_ID="2" pam_elogind.so does these things automatically, but everything should be possible to be done manually.
Even if you do specify seat manually, unless it was given to you at login time by pam_elogind.so, you will not have seat really. You will not be able to get control over DRM KMS as elogind deamon will simply reject your request for that, this also means that the input devices will not get ACL for your user. I do not see how that would work otherwise. The whole point of logind interface is to allow unprivileged user to gain privileged access to input devices and gain control over KMS, that requires CAP_SYS_ADMIN, so a process running as root, the elogind deamon in this scenario is the privileged entity. elogind have no use without pam module being enabled.
(In reply to Piotr Karbowski from comment #5) > You will not be able to get control over DRM KMS as elogind deamon will > simply reject your request for that, this also means that the input devices > will not get ACL for your user. > > I do not see how that would work otherwise. The whole point of logind > interface is to allow unprivileged user to gain privileged access to input > devices and gain control over KMS, that requires CAP_SYS_ADMIN, so a process > running as root, the elogind deamon in this scenario is the privileged > entity. Input devices (e.g. /dev/input/mouse0) are in "input" group. Video devices (e.g. /dev/dri/card0, /dev/fb0) are in "video" group. On my system with systemd and PAM and USE="pam" for all packages, when I tried startx as unprivileged user, the only way for it to actually work was to have my user account in "input" group and "video" group. Also neither pam_systemd(8) man page nor pam_elogind(8) man page say that pam_systemd.so / pam_elogind.so would grant access to any devices. These modules create /run/user/$UID directory and initialize some XDG_* variables. https://www.freedesktop.org/software/systemd/man/pam_systemd.html It seems to me that functionality of pam_systemd.so / pam_elogind.so is orthogonal to ability of running X server as unprivileged user. And being in appropriate groups would be the deciding factor for running X server as unprivileged user.
> And being in appropriate groups would be the deciding factor for running X server as unprivileged user. unfortunately not. I think it will be best if you just try it yourself. Try to start X as unprivileged user without a logind seat and then you will see permission denied on SETMASTER ioctl call. Although input group membership will workaround the lack of input devices access when running as unprivileged user without logind seat, video group membership *doesn't* let you take over KMS. the SETMASTER is a privileged call, if you do not wish to test it yourself, you can check kernel sources. Check the include/drm/drm_ioctl.h /** * @DRM_ROOT_ONLY: * * Anything that could potentially wreak a master file descriptor needs * to have this flag set. Current that's only for the SETMASTER and * DROPMASTER ioctl, which e.g. logind can call to force a non-behaving * master (display compositor) into compliance. * * This is equivalent to callers with the SYSADMIN capability. */ And the drivers/gpu/drm/drm_ioctl.c int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) { const struct drm_device *dev = file_priv->minor->dev; /* ROOT_ONLY is only for CAP_SYS_ADMIN */ if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) return -EACCES; So really, if you do not run with suid, and you run xorg-server as unprivileged user, unless you have a valid seat that let's you talk with logind, whatever it's the systemd's one or elogind's one, you won't be able to start X, you can even set on yourself, or xorg-server binary, the CAP_DAC_OVERRIDE that would ignore file permissions as if you were root, and it will still not get you working X. pam_elogind.so must be active upon login if you wish to start xorg-server as unprivileged user, unless you use some ancient hardware that does not have KMS/modeset drivers of course.
As we spoke on IRC, I will be closing it. Feel free to reopen it whenever you will do more testing on your end and come to a conclusion that it's indeed valid.
*** Bug 717648 has been marked as a duplicate of this bug. ***
(In reply to Piotr Karbowski from comment #5) > elogind have no use without pam module being enabled. Great! How do I get rid of it? I have no use for a notion of "seats." My desktop computer has only one seat, and I am the only user who sits in it. My installation works completely fine without PAM. I use SDDM as my display manager; my Xorg binary is *not* set-UID; my user is in the 'video' group but *not* the 'input' group; and I have no problems logging in and using my KDE Plasma session as I want to. Screen locking works; unprivileged mounting of removable disks works; unprivileged rebooting of the machine works. As far as I can tell, elogind (and ConsoleKit2 before it) gives me no utility whatsoever. I especially do not want to enable PAM, and as far as I can see, there's no reason for me to. I put sys-auth/pambase in package.provided, and all is well.
(In reply to Matt Whitlock from comment #10) > Is your Xorg process running as root? Do you want it to be? What value do you derive by not using pam?
(In reply to Matt Turner from comment #11) > Is your Xorg process running as root? Yes. It's started by /etc/init.d/xdm. Does that init script support starting X as an unprivileged user? Which user? > Do you want it to be? I have no strong opinion. > What value do you derive by not using pam? That's like asking "what value do you derive by not using systemd?" For one, smaller attack surface. Also, I've been burned badly by trying to enable PAM in the past, and it left a bad taste in my mouth. Besides, PAM seems way over-engineered to me, like so much stuff coming out of FreeDesktop.org in the past decade. /etc/passwd works fine for me. Gentoo is about choice, right? I choose to K.I.S.S.
(In reply to Matt Whitlock from comment #12) > (In reply to Matt Turner from comment #11) > > Is your Xorg process running as root? > > Yes. It's started by /etc/init.d/xdm. Does that init script support starting > X as an unprivileged user? Which user? > > > Do you want it to be? > > I have no strong opinion. > > > What value do you derive by not using pam? > > That's like asking "what value do you derive by not using systemd?" For one, > smaller attack surface. Also, I've been burned badly by trying to enable PAM > in the past, and it left a bad taste in my mouth. Besides, PAM seems way > over-engineered to me, like so much stuff coming out of FreeDesktop.org in > the past decade. /etc/passwd works fine for me. Gentoo is about choice, > right? I choose to K.I.S.S. So, here's the thing. You're saying you want a smaller attack surface, but you're running Xorg as root. I guarantee you that the smaller attack surface is provided by a rootless Xorg that delegates a very small amount of work to elogind. pam+pambase is less than 4MB on my system and I've never had to touch it. I have no idea why you bring up /etc/passwd. Sure, there are a bunch of pam modules that allow other forms of authentication, but pam doesn't throw out /etc/passwd. I think attempting to build a Linux system that goes way off the beaten path is decidedly not keeping it simple. Perhaps you should give elogind+pam another try?
(In reply to Piotr Karbowski from comment #3) > Adding pam flag there creates artificial dependency. The xorg-server itself > does not uses pam, however xorg-server will not be able to use elogind > integration without pambase[elogind]. > > ... > > Once the elogind will go default in desktop profiles (as per > https://bugs.gentoo.org/682160) I think we then could remove this pambase > dependency, as it's just to ensure that *most* people end up with working > elogind integration as for now. Should this be done now?
I think this is not really a way to go after all. There's runtime dependency on pambase have enabled elogind for elogind to work on Xorg. With pambase[-elogind] you won't get seat, so X won't be able to get control over display. If you decide to not use elogind and/or pam, you can do it, but it will just require going extra mile to disable those use flags. If you use a login manager that starts X as root, you can live without elogind integration, and go extra mile to disable *default* USE flags. For the sake of users, as long as pambase do have elogind use flag I do consider it a runtime dependency that shall remain.
(In reply to Matt Turner from comment #13) > So, here's the thing. You're saying you want a smaller attack surface, but > you're running Xorg as root. I guarantee you that the smaller attack surface > is provided by a rootless Xorg that delegates a very small amount of work to > elogind. Evidently there has been very little progress in getting SDDM to launch the X server as a non-root user. I don't particularly want to log in with agetty and then manually startx. (What year are we in again?) As long as SDDM is launching X as root anyway, elogind provides me no benefit. > pam+pambase is less than 4MB on my system and I've never had to touch it. I > have no idea why you bring up /etc/passwd. Sure, there are a bunch of pam > modules that allow other forms of authentication, but pam doesn't throw out > /etc/passwd. What I was trying to say is that the classic getpwent(3) (and getspent(3) from sys-apps/shadow) are not broken. I have no need to check user login credentials against LDAP or SQL or Active Directory or whatever. Therefore, I prefer not to build support for those alternatives. > I think attempting to build a Linux system that goes way off the beaten path > is decidedly not keeping it simple. From my perspective, PAM is off the beaten path. The beaten path is good old-fangled Unix account management. > Perhaps you should give elogind+pam another try? Because of your comments, I actually did start looking into trying this again, but as soon as I discovered that SDDM can't launch X as non-root, I lost interest, as I have nothing to gain.
> Because of your comments, I actually did start looking into trying this again, > but as soon as I discovered that SDDM can't launch X as non-root, I lost > interest, as I have nothing to gain. elogind provides you a seat, which means your DE/WM can utilize suspend/hibernate/poweroff/reboot via logind interface. Even with X still as root, that's nice to have.
(In reply to Matt Whitlock from comment #16) > (In reply to Matt Turner from comment #13) > > So, here's the thing. You're saying you want a smaller attack surface, but > > you're running Xorg as root. I guarantee you that the smaller attack surface > > is provided by a rootless Xorg that delegates a very small amount of work to > > elogind. > > Evidently there has been very little progress in getting SDDM to launch the > X server as a non-root user. I don't particularly want to log in with agetty > and then manually startx. (What year are we in again?) You can't ask what year are we again while subsequently complaining that PAM is too newfangled -- it's from 1995 (https://en.wikipedia.org/wiki/Pluggable_authentication_module) and came out of a UNIX vendor -- not Freedesktop.org. That you thought it was somehow a Freedesktop.org project should make you check your biases... Believe what you want. Just please stop complaining to me about it. I don't *need* to waste my time trying to help you configure your system, much less convince you of anything. But back to the matter at hand. https://github.com/sddm/sddm/issues/246 says that you need to use the "-keeptty" flag: /etc/sddm.conf: ServerArguments=-nolisten tcp -keeptty
(In reply to Matt Turner from comment #18) > https://github.com/sddm/sddm/issues/246 https://github.com/sddm/sddm/pull/673 was closed without having been merged, thus why I said "very little progress" and not "no progress." SDDM still doesn't support starting X as a non-root user, and the effort that had begun to get it there was summarily dismissed in August of last year.
(In reply to Matt Whitlock from comment #19) > (In reply to Matt Turner from comment #18) > > https://github.com/sddm/sddm/issues/246 > > https://github.com/sddm/sddm/pull/673 was closed without having been merged, > thus why I said "very little progress" and not "no progress." SDDM still > doesn't support starting X as a non-root user, and the effort that had begun > to get it there was summarily dismissed in August of last year. Are you saying that > /etc/sddm.conf: ServerArguments=-nolisten tcp -keeptty is not enough? Does that not work for you? Or are you saying that the logind integration works but sddm still runs X as root?
(In reply to Matt Turner from comment #20) I'm saying, SDDM presently can only start X as root. Further development work is needed in order to make SDDM start X as a non-root user. Per https://github.com/sddm/sddm/issues/246#issuecomment-538721378, -keeptty will become relevant only after SDDM has been enhanced to start X as a non-root user. See also: Bug 603294 Comment 10.
