1 |
Hi, |
2 |
|
3 |
I'd like to discuss here the current state of elogind integration as a |
4 |
whole, and the follow-up work that is now required, after I've put a |
5 |
default on local USE flag +elogind on xorg-server while dropping default |
6 |
suid flag in my commit yesterday. |
7 |
|
8 |
The motivation on the changes was to follow up the removal of default |
9 |
+suid that happened in November last years, that sadly had to be |
10 |
reverted. Now with elogind integration, non-systemd users got all that |
11 |
they need to run Xorg as a unprivileged user. |
12 |
|
13 |
The status of xorg-server at this very moment is that it no longer |
14 |
defaults to be merged with suid, however, now it defaults to +elogind. |
15 |
This have the following implications: |
16 |
|
17 |
- User will be prompted that pambase requires +elogind, which is not |
18 |
enabled by default -- meaning that simple `emerge xorg-server` will |
19 |
prompt user to add package.use entry. This could be solved by always |
20 |
having the elogind bits enabled, the same way a gnome-keyring is, so the |
21 |
pam_elogind.so is used if present. This shouldn't have any negative |
22 |
effect on for instance systemd users, as systemd cannot be installed at |
23 |
the same time as elogind. |
24 |
|
25 |
- systemd users that does not use systemd profiles will be required to |
26 |
alter package.use or make.conf USE flags definition to drop -elogind |
27 |
there, as otherwise xorg-server will refuse to be merged due to |
28 |
at-most-one-of ( elogind systemd ) condition there. However those |
29 |
systemd users that do use systemd profiles will not run into any things |
30 |
to do, as systemd's use.mask have elogind there. |
31 |
|
32 |
- The desktop profiles enables +consolekit, which conflicts with elogind |
33 |
-- the users of those profiles will need to adjust USE flags. |
34 |
|
35 |
- OpenRC/non-systemd users are now able to run X without suid, as |
36 |
elogind is the entity that wraps the SETMASTER, no more "ioctl |
37 |
permission denied" on starting X as unprivileged user. |
38 |
|
39 |
After speaking with some of you on #-dev and #-desktop I know that the |
40 |
opinions on that vary, arguably enabling elogind local USE flag on |
41 |
xorg-server was somewhat ahead of time, leaving some users in |
42 |
unfavorable position where the xorg-server installation will require |
43 |
them to manually modify package.use/make.conf. |
44 |
|
45 |
Some of the ideas that were pointed on IRC (forgive me if I missed some): |
46 |
|
47 |
- We should go back to +suid -elogind default. |
48 |
- We should actually NOT put suid on Xorg if USE="suid elogind" but put |
49 |
suid bit with USE="suid -elogind". |
50 |
- We should only ever enable elogind in desktop profiles. |
51 |
|
52 |
Personally I'd like to stay without enabling suid by default on |
53 |
xorg-server, as otherwise hardly anyone will ever drop the suid from it, |
54 |
which would be a big step back. Gentoo tried to drop suid from |
55 |
xorg-server a handful of times, let's make the current one a final one :) |
56 |
|
57 |
I'd like to propose doing the following: |
58 |
|
59 |
- Keywording elogind on missing archs |
60 |
- Making elogind a global USE flag |
61 |
- Switching desktop profiles to elogind from consolekit while still |
62 |
preserving -suid +elogind on xorg-server for those that does not use |
63 |
desktop profiles (systemd profiles users not affected) |
64 |
- Making pambase always install the configuration for pam_elogind.so, |
65 |
the same way it does for pam_gnome_keyring.so at this very moment, |
66 |
effectively removing elogind USE flag from it. |
67 |
|
68 |
What do you all think about? |
69 |
|
70 |
-- Piotr. |