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

[Michał Górny]

On Fri, 2019-03-22 at 21:32 +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".

This is a horrible idea.  While some people think it's cool to have
flags magically fit a random definition of a 'sane thing' in insane
combinations, it's confusing to everyone.

> - 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.
>
> What do you all think about?
>

My suggestion would be to focus on having sane defaults in all profiles,
and sane flags.  AFAIU logind makes sense on desktop profiles.  So
enable it globally in desktop profiles, then replace it with systemd
in systemd subprofiles.

Don't do USE defaults.  People who don't use desktop profiles can live
with having to fine-tune xorg-server.  Worst case, in the generic case
use REQUIRED_USE to force them to choose one of the options.

-- 
Best regards,
Michał Górny