Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

[Andrew Savchenko <bircoph@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4089 bytes --]

On Fri, 22 Mar 2019 21:32:16 +0100 Piotr Karbowski wrote:
> Hi,
> 
> I'd like to discuss here the current state of elogind integration as a
> whole, and the follow-up work that is now required, after I've put a
> default on local USE flag +elogind on xorg-server while dropping default
> suid flag in my commit yesterday.
> 
> The motivation on the changes was to follow up the removal of default
> +suid that happened in November last years, that sadly had to be
> reverted. Now with elogind integration, non-systemd users got all that
> they need to run Xorg as a unprivileged user.
> 
> The status of xorg-server at this very moment is that it no longer
> defaults to be merged with suid, however, now it defaults to +elogind.
> This have the following implications:
> 
> - User will be prompted that pambase requires +elogind, which is not
> enabled by default -- meaning that simple `emerge xorg-server` will
> prompt user to add package.use entry. This could be solved by always
> having the elogind bits enabled, the same way a gnome-keyring is, so the
> pam_elogind.so is used if present. This shouldn't have any negative
> effect on for instance systemd users, as systemd cannot be installed at
> the same time as elogind.
> 
> - systemd users that does not use systemd profiles will be required to
> alter package.use or make.conf USE flags definition to drop -elogind
> there, as otherwise xorg-server will refuse to be merged due to
> at-most-one-of ( elogind systemd ) condition there. However those
> systemd users that do use systemd profiles will not run into any things
> to do, as systemd's use.mask have elogind there.
> 
> - The desktop profiles enables +consolekit, which conflicts with elogind
> -- the users of those profiles will need to adjust USE flags.
> 
> - OpenRC/non-systemd users are now able to run X without suid, as
> elogind is the entity that wraps the SETMASTER, no more "ioctl
> permission denied" on starting X as unprivileged user.
> 
> After speaking with some of you on #-dev and #-desktop I know that the
> opinions on that vary, arguably enabling elogind local USE flag on
> xorg-server was somewhat ahead of time, leaving some users in
> unfavorable position where the xorg-server installation will require
> them to manually modify package.use/make.conf.
> 
> Some of the ideas that were pointed on IRC (forgive me if I missed some):
> 
> - We should go back to +suid -elogind default.
> - We should actually NOT put suid on Xorg if USE="suid elogind" but put
> suid bit with USE="suid -elogind".
> - We should only ever enable elogind in desktop profiles.
> 
> Personally I'd like to stay without enabling suid by default on
> xorg-server, as otherwise hardly anyone will ever drop the suid from it,
> which would be a big step back. Gentoo tried to drop suid from
> xorg-server a handful of times, let's make the current one a final one :)
> 
> I'd like to propose doing the following:
> 
> - Keywording elogind on missing archs
> - Making elogind a global USE flag
> - Switching desktop profiles to elogind from consolekit while still
> preserving -suid +elogind on xorg-server for those that does not use
> desktop profiles (systemd profiles users not affected)
> - Making pambase always install the configuration for pam_elogind.so,
> the same way it does for pam_gnome_keyring.so at this very moment,
> effectively removing elogind USE flag from it.

Maybe that's a good time to make USE flag for pam_gnome_keyring.so.
Really, we shouldn't force users with some crap just "because it
doesn't hurt (much)".
 
> What do you all think about?

Currently PAM warns if more than single session tracker is enabled
(consolekit, elogind, systemd). Enabling one implicitly by default
will likely create problems for users of other session tracker.

As for me personally, I do not use session trackers at all, they
are banned from all my setups for good. Though as long as this is
configurable, I don't really care about defaults.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]