Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
В Пт, 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 optionalpam_gnome_keyring.so use_authtok
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
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. pEpkey.asc Description: application/pgp-keys
Re: [gentoo-dev] New global flag: elogind
On Dienstag, 23. Oktober 2018 08:46:51 CET Michał Górny wrote: > How about: > > elogind - Enable session tracking via sys-auth/elogind It is high time to do that.
[gentoo-dev] Last rites: dev-lua/luvit
# Michał Górny (22 Mar 2019) # Unmaintained. No reverse dependencies. The current Gentoo version # is from 2015, and upstream has made a lot of releases since. # It suffers from heavy bundling of dependencies. # Removal in 30 days. Bug #469194. dev-lua/luvit -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
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.
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 pgp9X1hZnO3mp.pgp Description: PGP signature
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
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. pEpkey.asc Description: application/pgp-keys
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
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 pgpU74agEv0xv.pgp Description: PGP signature
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
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.
pEpkey.asc
Description: application/pgp-keys
Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
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.
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
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.
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. pEpkey.asc Description: application/pgp-keys
[gentoo-dev] Last rites: x11-wm/afterstep
# Michał Górny (22 Mar 2019) # Unmaintained. Last release in 2013, last commits in 2015. Nested # bundled libraries (#253259, also causing #515384). Fails to build # with [-dbus] (#560208). # Removal in 30 days. Bug #681294. x11-wm/afterstep -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-roguelike/rogue
# Michał Górny (22 Mar 2019) # Unmaintained, dead homepage (#680752). Fails to build against # ncurses[tinfo] (#459490), fails to build against ncurses-6 (#649794). # Also has some unresolved segv (#407983). # Removal in 30 days. Bug #459490. games-roguelike/rogue -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-vpn/aiccu
# Michał Górny (22 Mar 2019) # SixXS has been discontinued, rendering the package defunct. # Removal in 30 days. Bug #670678. net-vpn/aiccu -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-misc/sjphone
# Michał Górny (22 Mar 2019) # omepage dead, and package is mirror-restricted. Current release # was added in 2006 and has not been updated since. # Removal in 30 days. Bug #681230. net-misc/sjphone -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
