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 |