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

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

[Piotr Karbowski]

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

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.

What do you all think about?

-- Piotr.

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 6297 bytes --]

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

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 902 bytes --]

On 3/22/2019 4:32 PM, Piotr Karbowski wrote:
> Hi,
> 
> 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?
> 
> -- Piotr.
> 

What are the implications, if any, of using DMs which are not aware of
{,e}logind?  Do they work without modification?

Afaik, only sddm or, now, gdm even have an elogind USE flag.

All other DMs have consolekit support but unknown elogind status.

Brian


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

[Andreas Sturmlechner]

Short anwer: Right now, xorg-server[+elogind] is at odds with desktop profile 
that still has +consolekit by default.

For good reasons (long answer):

elogind integration tracker not yet done: https://bugs.gentoo.org/599470
bluez hard-requiring systemd with user-session: https://bugs.gentoo.org/639434
Besides the above, have we really identified all packages that need fixing? I 
certainly haven't made an attempt.

Here's how these flags relate, and how they should be set globally:
?? ( consolekit elogind systemd )

We know from previous fallout (skypeforlinux) that merely having elogind 
installed besides a system built with +consolekit globally will result in 
runtime issues.

Therefore, not one single package, unless it hard-depends on exactly-one-of ( 
elogind systemd ) should enable elogind by default at this time. Doing so now 
only makes people switch it off globally either before or after they are facing 
runtime issues.

Let's fix the remaining bugs, create a proper news item in advance, and then 
switch over desktop profiles to elogind as the new default.

Regards,
Andreas

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

[Piotr Karbowski]

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

Hi,

On 22/03/2019 21.43, Brian Evans wrote:
> What are the implications, if any, of using DMs which are not aware of
> {,e}logind?  Do they work without modification?

My understanding is that such DMs, like lightdm, fork X as root anyway,
so there's no implication here, regardless if you have -elogind or
+elogind on xorg-server. Even more, you can have -suid -elogind -systemd
on xorg-server for lightdm and it will work, as again, it starts as root.

The relation between xorg-server and elogind is that pam_elogind.so
provides user upon login with variables like $XDG_VTNR, that Xorg then
uses, when you start X as user, to start X on the very same virtual
terminal that one logged in, and then, elogind (started via dbus or
manually) pass the SETMASTER ioctl.

-- Piotr.

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 6297 bytes --]

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

[Andrew Savchenko]

[-- 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 --]

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

[Piotr Karbowski]

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

Hi,

On 22/03/2019 21.47, Andreas Sturmlechner wrote:
> Therefore, not one single package, unless it hard-depends on exactly-one-of ( 
> elogind systemd ) should enable elogind by default at this time. Doing so now 
> only makes people switch it off globally either before or after they are facing 
> runtime issues.
> 
> Let's fix the remaining bugs, create a proper news item in advance, and then 
> switch over desktop profiles to elogind as the new default.

So, what you propose is to go IUSE="+suid elogind" on xorg-server for
now, until elogind has full blown support, and then enabling +elogind in
desktop profile?

I am not a big fan of that, but for sure, that would address the issues,
however I am really worried about what to do later with xorg-server. I
*really* do not want suid to be enabled there by default permanently, if
we go the following route, do you think it's feasible to then still
default to +elogind -suid on xorg-server? I understood now that
consolekit clash with elogind, but maybe it's something to handle on
consolekit level, to block elogind from being installed?

This way the users of default profile would defaults to elogind on
xorg-server, and if they desire to use consolekit, they will need to add
-elogind for xorg-server, and adding +suid if they do not use DM that
starts X for them as root.

-- Piotr.

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 6297 bytes --]

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

[Roy Bamford]

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

On 2019.03.22 20:32, Piotr Karbowski wrote:
> Hi,
> 
[snip]

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

This looks broken by default.
[ebuild   R    ] x11-base/xorg-server-1.20.4:0/1.20.4::gentoo  USE="doc glamor ipv6 udev xorg xvfb -debug -dmx (-elogind) -kdrive -libressl -minimal (-selinux) -static-libs -suid* -systemd -unwind -wayland -xcsecurity -xephyr -xnest" 

elogind is hard masked and suid is being turned off.
Its arm64, so I expect to find a few rough edges.

However, changes like this need to be coordinated across all arches.
Take a pat on the back for the elogind work and a slap on the wrist
if my arm64 systems don't work any more.

Its still building, I'll test later.  

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

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

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

[Andreas Sturmlechner]

On Freitag, 22. März 2019 22:07:54 CET Piotr Karbowski wrote:
> I am not a big fan of that, but for sure, that would address the issues,
> however I am really worried about what to do later with xorg-server. I
> *really* do not want suid to be enabled there by default permanently, if
> we go the following route, do you think it's feasible to then still
> default to +elogind -suid on xorg-server? I understood now that
> consolekit clash with elogind, but maybe it's something to handle on
> consolekit level, to block elogind from being installed?

That would be introducing a default blocker to desktop profiles, and we don't 
do that to our users.

This should be instead a huge motivation to get elogind support on track 
everywhere it is still lacking, fix blockers, identify (the importance of) yet-
consolekit-only packages. Maybe create a tracker for the switch to elogind on 
desktop profiles.

Regards,
Andreas

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

[Michał Górny]

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

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Piotr Karbowski]

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

Hi,

For time being the IUSE has been reverted to the old +suid, elogind is
now opt-in and not enabled by default. This preserves the old,
working-for-everyone-everywhere default flags.

-- Piotr.

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 6297 bytes --]

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

[Alexander Tsoy]

В Пт, 22/03/2019 в 23:56 +0300, Andrew Savchenko пишет:
--------------->%---------------
> > - 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)".

There used to be a gnome-keyring USE flag that controlled auto-
launching of gnome-keyring-daemon on user login. But now support for
gnome-keyring in pambase is pretty minimal, clearly not deserving a USE
flag:

$ portageq match / pambase 
sys-auth/pambase-20150213-r2
$ portageq contents / sys-auth/pambase-20150213-r2 | xargs grep
gnome_keyring 2>/dev/null
/etc/pam.d/passwd:-password	optional	pam_gnome_keyring.so
use_authtok