Gentoo Archives: gentoo-dev

From: Andrew Savchenko <bircoph@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
Date: Fri, 22 Mar 2019 20:56:54
Message-Id: 20190322235643.2bd9ed7e5a09c7bddac24fca@gentoo.org
In Reply to: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server. by Piotr Karbowski
1 On Fri, 22 Mar 2019 21:32:16 +0100 Piotr Karbowski wrote:
2 > Hi,
3 >
4 > I'd like to discuss here the current state of elogind integration as a
5 > whole, and the follow-up work that is now required, after I've put a
6 > default on local USE flag +elogind on xorg-server while dropping default
7 > suid flag in my commit yesterday.
8 >
9 > The motivation on the changes was to follow up the removal of default
10 > +suid that happened in November last years, that sadly had to be
11 > reverted. Now with elogind integration, non-systemd users got all that
12 > they need to run Xorg as a unprivileged user.
13 >
14 > The status of xorg-server at this very moment is that it no longer
15 > defaults to be merged with suid, however, now it defaults to +elogind.
16 > This have the following implications:
17 >
18 > - User will be prompted that pambase requires +elogind, which is not
19 > enabled by default -- meaning that simple `emerge xorg-server` will
20 > prompt user to add package.use entry. This could be solved by always
21 > having the elogind bits enabled, the same way a gnome-keyring is, so the
22 > pam_elogind.so is used if present. This shouldn't have any negative
23 > effect on for instance systemd users, as systemd cannot be installed at
24 > the same time as elogind.
25 >
26 > - systemd users that does not use systemd profiles will be required to
27 > alter package.use or make.conf USE flags definition to drop -elogind
28 > there, as otherwise xorg-server will refuse to be merged due to
29 > at-most-one-of ( elogind systemd ) condition there. However those
30 > systemd users that do use systemd profiles will not run into any things
31 > to do, as systemd's use.mask have elogind there.
32 >
33 > - The desktop profiles enables +consolekit, which conflicts with elogind
34 > -- the users of those profiles will need to adjust USE flags.
35 >
36 > - OpenRC/non-systemd users are now able to run X without suid, as
37 > elogind is the entity that wraps the SETMASTER, no more "ioctl
38 > permission denied" on starting X as unprivileged user.
39 >
40 > After speaking with some of you on #-dev and #-desktop I know that the
41 > opinions on that vary, arguably enabling elogind local USE flag on
42 > xorg-server was somewhat ahead of time, leaving some users in
43 > unfavorable position where the xorg-server installation will require
44 > them to manually modify package.use/make.conf.
45 >
46 > Some of the ideas that were pointed on IRC (forgive me if I missed some):
47 >
48 > - We should go back to +suid -elogind default.
49 > - We should actually NOT put suid on Xorg if USE="suid elogind" but put
50 > suid bit with USE="suid -elogind".
51 > - We should only ever enable elogind in desktop profiles.
52 >
53 > Personally I'd like to stay without enabling suid by default on
54 > xorg-server, as otherwise hardly anyone will ever drop the suid from it,
55 > which would be a big step back. Gentoo tried to drop suid from
56 > xorg-server a handful of times, let's make the current one a final one :)
57 >
58 > I'd like to propose doing the following:
59 >
60 > - Keywording elogind on missing archs
61 > - Making elogind a global USE flag
62 > - Switching desktop profiles to elogind from consolekit while still
63 > preserving -suid +elogind on xorg-server for those that does not use
64 > desktop profiles (systemd profiles users not affected)
65 > - Making pambase always install the configuration for pam_elogind.so,
66 > the same way it does for pam_gnome_keyring.so at this very moment,
67 > effectively removing elogind USE flag from it.
68
69 Maybe that's a good time to make USE flag for pam_gnome_keyring.so.
70 Really, we shouldn't force users with some crap just "because it
71 doesn't hurt (much)".
72
73 > What do you all think about?
74
75 Currently PAM warns if more than single session tracker is enabled
76 (consolekit, elogind, systemd). Enabling one implicitly by default
77 will likely create problems for users of other session tracker.
78
79 As for me personally, I do not use session trackers at all, they
80 are banned from all my setups for good. Though as long as this is
81 configurable, I don't really care about defaults.
82
83 Best regards,
84 Andrew Savchenko

Replies