Re: [gentoo-dev] Packages up for grabs: x11-misc/gmrun
Hi, On 17/01/2021 16.57, Jonas Stein wrote: > Dear all > > the following packages are up for grabs after dropping > desktop-misc: > > x11-misc/gmrun > https://packages.gentoo.org/packages/x11-misc/gmrun I will grab the gmrun. -- Piotr.
[gentoo-dev] sys-power/bbswitch up for grabs
Hi, I've been maintaining sys-power/bbswitch in the recent times, however, I no longer have any hardware where I can even test it. If anyone sees it fit, feel free to grab it and join other maintainers there. I just dropped myself out of metadata.xml. Open bugs: - https://bugs.gentoo.org/761370 - https://bugs.gentoo.org/613338 -- Piotr.
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
Hi, On 25/11/2020 22.57, Georgy Yakovlev wrote: > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, > and is just a drop-in replacement, the only step needed is to emerge the > package. > it's a simple single binary + manpage, binary links to libacl and couple other > system libs. Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been using it since end of October. Two things that are different in terms of interface to opentmpfiles is that systemd-tmpfiles does not have --dry-run runtime option, and it will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of /run, but that's just an warning. Regardless, it's just a drop-in replacement, have not noticed any issues. -- Piotr.
Re: [gentoo-dev] GNU Guix
On 29/09/2020 16.02, William Breathitt Gray wrote: > Cuckoo is a spam bot. The bot assumes the first response will be a user > pointing out that the link is dangerous. So the bot's response is to > respond back automatically with an aggressive denial in the hopes that > more users will continue to click the spam link. So the day has come when a script has fooled me. Thanks for clarification. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GNU Guix
On 29/09/2020 14.26, Cuckoo's Calling wrote: > You are so naive and I couldn't stop laughing. I would appreciate it If you'd refrain from sending such messages to mailing list, either go into details when you disagree with people or don't reply at all. Those low level flexing is not welcome here. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stabilisation of app-admin/ansible-2.10.0
Hi, The current state is that the Ansible in tree is not working due to fact that it misses core modules. I'd say 2.10.0 should be masked, as ~arch or stable arch, it does not work, then revbump to use bundle package, not ansible-base. If maintainer want to split it into ansible-base + separated ebuilds for modules, then maintainer should prepare a news item, as the update replaces working Ansible with something that cannot work by itself, and there's no interfaces to take in rest of needed parts as by now. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages are up for grabs: zathura and co
On 24/08/2020 13.57, Mikle Kolyada wrote: > dev-libs/girara > app-text/zathura-ps > app-text/zathura-pdf-poppler > app-text/zathura-pdf-mupdf > app-text/zathura-djvu > app-text/zathura-cb > app-text/zathura > > > Are for grabs now, I do not use them daily anymore. A separate active > maintainer needed. > > I will take over zathura packages since I use it on daily basis. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
On 11/08/2020 15.38, Joonas Niilola wrote: > > On 8/11/20 11:36 AM, Jaco Kroon wrote: >> And I've already provided you one use case where udev doesn't work well >> but eudev does. I've also mentioned some historic issues I believe >> should already be fixed but which did bit me in systemd-udev which was >> never a problem in eudev. >> > Your systems seem to diverge a lot from what I'd consider as 'default'. > You must already make many changes to them. > > Before this thread I didn't even know/remember I was using eudev. It > works and there doesn't seem to be any global issues related to it. > However after reading this thread I'm a bit considered about the > maintenance state of it. > > Switched to udev. Simple as 'emerge -1 sys-fs/udev'. It works, didn't > notice any difference. > > If musl is a problem, to my knowledge musl has its own stage images, so > why can't those stages use eudev while other ones defaulting to udev? For the sake of science, I've also moved one of my systems to sys-fs/udev and noticed a single incompatibility. There are few ways how to disable the systemd/udev predictable NIC names, one of them is to boot with net.ifnames=0, another is to mask rule file that trigger the rename, as described on wiki[1] Long story short, on eudev it's 80-net-name-slot.rules, on udev it's 80-net-setup-link.rules The result was that my system booted without working network, as connman started to poke around Ethernet interfaces (this is ok, I had blacklisted eth*, not enp*), which then resulted in switching routing to Ethernet that failed to get IP from DHCP, even that WiFi had a fully working Internet access, so more like connman bug. (And yes, I am aware that net.ifnames=0 will work on both) This however shows two things: eudev is (no longer) drop-in replacement, as some interfaces changed in upstream udev, which leads to second thing, we need to have migration path, because even if(!) Gentoo change default (I am not a fan of this idea really), then it might lead to people doing fresh installation or reinstallation, migrating their configs resulting in not working systems/working in other way that previous one. [1] https://wiki.gentoo.org/wiki/Udev#Keep_classic_.27eth0.27_naming -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
Hi, To summarize - There's no known bugs in eudev that are not in udev - There's no bug that would be fixed by switch from eudev to udev - There's no new feature that would change eudev to udev bring - Currently musl and glibc profiles uses common eudev, after change we whould have musl profile users use something that glibc users are not using - You don't like the original decision to switch to eudev so you want now to use uno reverse card. - eudev have single maintainer, but so far it did not had negative impact on Gentoo I see no reason to switch to sys-fs/udev by default, up until there's actually a technical reason behind it. The eudev is a thing because systemd upstream made it clear that they have no intention into keeping udev operational unless it runs under systemd, which is quite important here. -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Last-rites: net-p2p/nicotine+
Hi, On 18/07/2020 15.09, Andreas Sturmlechner wrote: > # Andreas Sturmlechner (2020-07-18) > # Stuck on Python 2, depends on deprecated dev-python/pygtk, bug #708162. > # Needs a maintainer and >=2.0.1 version bump. Masked for removal in 30 days. > net-p2p/nicotine+ > Will pick it up. -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: */* More Py2 only items
On 29/06/2020 02.35, Aaron Bauman wrote: > [...] > net-dns/maradns There's single python script that can work with Python3 (at least in new version) that does that can just use any Python version. I see that it did not got update for over a year, will take it over now and push update tomorrow, then drop your mask on this package. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: News item: xorg-server dropping default suid
Hi, On 21/06/2020 22.27, Michał Górny wrote: > No offense but it sounds a little chaotic to me. Which is the reasons we do those reviews. Appreciate the suggestions, just sent revision 2 as the response to the very first email in this thread, please check how it looks now. -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: News item: xorg-server dropping default suid
Title: xorg-server dropping default suid Author: Piotr Karbowski Posted: 2020-06-22 Revision: 2 News-Item-Format: 2.0 Display-If-Installed: x11-base/xorg-server Starting 2020-07-15, x11-base/xorg-server will default to using the logind interface instead of suid by default. resulting in better security by default through running the server as a regular user instead of root. However, this will require our users to use a logind provider such as elogind or systemd. The systemd users and those who are not using systemd but use desktop profiles can stop reading here, as they already have a logind provider enabled. Others, who have neither systemd or desktop profiles enabled will be required to globally enable 'elogind' USE flag and update the system # emerge --newuse @world Afterwards, one will need to re-login, so the PAM can assign a seat. One can confirm that a seat has been assigned upon login by running: $ loginctl user-status Users who do not wish to use logind interface or have rare hardware that does not use KMS and because of that, require root privileges to operate, can manually re-enable 'suid' and disable 'elogind' USE flags in order to preserve the previous behavior. However, please note that this is heavily discouraged to run X server as root due to security reasons. The 'suid' USE flag will remain as optional opt-in for the need of legacy hardware. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: News item: xorg-server dropping default suid
Hi, On 22/06/2020 06.03, Philip Webb wrote: [...] > I don't want to use 'systemd', as I want to run a traditional UNIX version > of Linux + KDE (or Fluxbox) for a simple single-user desktop system. Then... don't use systemd? I officially give you my approval for that. Read what you quoted in your email, elogind is standalone package. The elogind does work normally in the configuration with OpenRC and startx. > So i ask again : Why is running 'xorg-server' as root "heavily discouraged" ? It's common sense to run software with the least privileges they require, so if new attack vector is discovered, perhaps there will be no escalation surface to make use of it. -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: News item: xorg-server dropping default suid
Hi, Re-sending news item inline. ### Title: xorg-server dropping default suid Author: Piotr Karbowski Posted: 2020-06-22 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: x11-base/xorg-server The Gentoo X11 Team is announcing that starting with 15th of July, the x11-base/xorg-server will no longer default to suid and will default to using logind interface instead. This change makes xorg-server run as regular user rather than root by default, however, those who do not have any logind interface provider (either systemd or elogind) will need to enable either to make it possible to run X session as unprivileged user. No action is required from systemd and desktop profile users, since systemd provides logind interface, and desktop profile already enables 'elogind' USE flag globally. Rest of the non-systemd users is required to globally enable 'elogind' USE flag and apply it by 'emerge --newuse @world', after which, re-login is required so that PAM can allocate seat. One can confirm that a seat has been assigned upon login by running: $ loginctl user-status Those who for whatever reason want to preserve current state, while heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'. signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item: xorg-server dropping default suid
Hi, Please find news item attached. -- Piotr. Title: xorg-server dropping default suid Author: Piotr Karbowski Posted: 2020-06-22 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: x11-base/xorg-server The Gentoo X11 Team is announcing that starting with 15th of July, the x11-base/xorg-server will no longer default to suid and will default to using logind interface instead. This change makes xorg-server run as regular user rather than root by default, however, those who do not have any logind interface provider (either systemd or elogind) will need to enable either to make it possible to run X session as unprivileged user. No action is required from systemd and desktop profile users, since systemd provides logind interface, and desktop profile already enables 'elogind' USE flag globally. Rest of the non-systemd users is required to globally enable 'elogind' USE flag and apply it by 'emerge --newuse @world', after which, re-login is required so that PAM can allocate seat. One can confirm that a seat has been assigned upon login by running: $ loginctl user-status Those who for whatever reason want to preserve current state, while heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
Hi, On 27/05/2020 01.31, Brian Dolbec wrote: > * dev-python/boto3 > * dev-python/botocore Do you mind if I join you on those? I use them a lot, and I planned to comaintain awscli since Patrick is the only one current maintainer of those, boto3 is vital part of it too. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
Hi, On 26/05/2020 09.23, Philip Webb wrote: > 200526 Piotr Karbowski wrote: >> On 26/05/2020 00.34, Philip Webb wrote: >>> I'ld rather you didn't. >> You didn't provided any rationale for that. > > I thought I did (smile). > >> Running X as root is anti-pattern, especially nowadays >> when so little effort is required to not have to run it as root. > > I've never run X as root : it's not the UNIX way. I am not sure if you're trolling me here, or you genuinely not understand that regardless of what user you execute `startx` on, if Xorg have suid, it will start as root. >> You can either enable elogind > > Why would anyone want to abandon the long-successful UNIX method > & adopt some complex replacement ? I wouldn't call running X as root to be long successful UNIX method. Back in the days there was no way to ran X without root, now there is. >> or you can enable suid if you want to preserve your status quo, >> we're talking here about defaults >> that user can change if he has a reason to do so. > > Yes, this is a regular problem which is unavoidable : > what should the default be ? -- I want the default to be > what it's always been & what matches basic UNIX principles. > I can add 'suid' to 'xorg-server' in package.use , > but why should I have to ? -- over to you for a rationale (smile). I am not sure what kind of UNIX principles you're speaking about, the default should be reasonable, running X as root is not, if someone want to go against common sense and run X as root, he can do so, with defaults to not run it as root. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
Hi, On 26/05/2020 00.34, Philip Webb wrote: > I'ld rather you didn't. You didn't provided any rationale for that. Running X as root is anti pattern, especially nowadays when so little effort is required to not have to run it as root. You can either enable elogind, or you can enable suid if you want to preserve your status quo, we're talking here about defaults that user can change if he has a reason to do so. -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
Hi, For years the xorg-server in Gentoo was defaulting to be running with suid, even those that does not really require it, like systemd users and those who runs elogind still end up with X as uid 0 because of +suid default. Times has changed, we now have +elogind in desktop profile, xorg-server can no longer work without udev (due to input drivers), so there's no real benefit for defaulting to suid. There are 3 common ways the xorg-server is started: - via XDM of some sort, usually forked as root, does not require suid, systemd or elogind. - via better XDM that can into logind interface, started as regular user thanks to logind interface provided by either systemd or elogind. - via `startx`, if systemd or elogind are present, can work without suid, without them, suid is required. Flipping current '+suid (-)elogind' as *default* USE flags on ebuild level into '+elogind (-)suid' will not affect first two use cases, and affect only 3rd one if neither systemd is used, or elogind is enabled. What I'd like to go with is to enable elogind and disable suid on ebuild level. The systemd profiles have use.mask for elogind, meaning it's not a problem for them. and those who do not want to use any logind provider can still opt-out out of it and go back to use suid. It shouldn't really affect most of the users in any negative way, if anything, it will make more users to not run Xorg as root, which is a positive aspect. The alternative way would be to enable elogind on default profile, however it would also affect those who run headless Gentoo, of which a lot refuse to use any login manager. So, dear people of Gentoo, what do you think about turning the current possible opt-out of Xorg as root into possible opt-in for running Xorg as root? People still will have a choice, just the defaults will be more sane. -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last-rites: x11-drivers/xf86-input-{keyboard,mouse}
# Piotr Karbowski (2020-05-03) # Obsolete input drivers, use x11-drivers/xf86-input-libinput # or x11-drivers/xf86-input-evdev instead. # Removal in 30 days. x11-drivers/xf86-input-keyboard x11-drivers/xf86-input-mouse For more information see https://gitweb.gentoo.org/data/gentoo-news.git/tree/2020-04-03-deprecation-of-legacy-x11-input-drivers/2020-04-03-deprecation-of-legacy-x11-input-drivers.en.txt -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.
Hi, On 02/04/2020 17.26, Piotr Karbowski wrote: > Hi, > > Updated with what Ulm and Soup pointed out, while keeping the long > sentence, that even it's long, is still beneficial to have. Revision > bumped to 2, date bumped to tomorrow's. My apology, s/Soup/Soap/. -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.
Hi, Updated with what Ulm and Soup pointed out, while keeping the long sentence, that even it's long, is still beneficial to have. Revision bumped to 2, date bumped to tomorrow's. --- news item below --- Title: Deprecation of legacy X11 input drivers Author: Piotr Karbowski Posted: 2020-04-03 Revision: 2 News-Item-Format: 2.0 Display-If-Installed: x11-drivers/xf86-input-mouse Display-If-Installed: x11-drivers/xf86-input-keyboard The Gentoo X11 Team is announcing the deprecation and future removal of the legacy X11 input drivers x11-drivers/xf86-input-mouse and x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers will be masked for removal. These drivers have been deprecated for many years, first by xf86-input-evdev and then by xf86-input-libinput. The only use for those drivers remain in deployments which intentionally opt-out of using udev, as both evdev and libinput require udev during runtime, however given that upstream has already removed the Linux support from xf86-input-keyboard, future X11 releases will no longer support xf86-input-keyboard on Linux rendering those installation infeasible to use without udev. In order to ensure frictionless upgrade path for future X11 releases, we have decided to deprecate those drivers that are not in active use by pretty much any installation of Gentoo. No action is required from end-users who are already using libinput (or evdev). To check which driver is in use, one can use $ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log for the systems running xorg-server as regular user (-suid +elogind/+systemd) or by running # grep 'Using input driver' /var/log/Xorg.0.log for those running xorg-server as root. If however neither libinput or evdev is in use, one should append 'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf while removing 'keyboard' and 'mouse' if present, then update @world with new USE flags # emerge -N @world -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item: Deprecation and removal of legacy X11 input drivers.
Title: Deprecation and removal of legacy X11 input drivers. Author: Piotr Karbowski Posted: 2020-04-02 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: x11-drivers/xf86-input-mouse Display-If-Installed: x11-drivers/xf86-input-keyboard The Gentoo X11 Team is announcing the deprecation and future removal of the legacy X11 input drivers x11-drivers/xf86-input-mouse and x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers will be masked for removal. These drivers have been deprecated for many years, first by xf86-input-evdev and then by xf86-input-libinput. The only use for those drivers remain in deployments which intentionally opt-out of using udev, as both evdev and libinput require udev during runtime, however given that upstream has already removed the Linux support from xf86-input-keyboard, future X11 releases will no longer support xf86-input-keyboard on Linux rendering those installation infeasible to use without udev. In order to ensure fraction-less upgrade path for future X11 releases, we have decided to deprecate those drivers that are not in active use by pretty much any installation of Gentoo. No action is required from end-users who are already using libinput (or evdev). To check which driver is in use, one can use $ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log For the systems running xorg-server as regular user (-suid +elogind/+systemd) or by running # grep 'Using input driver' /var/log/Xorg.0.log for those that still runs xorg-server as root. If however neither libinput or evdev is in use, one should append 'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf and update @world with new USE flags # emerge -N @world signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Hi, On 18/12/2019 22.08, Michał Górny wrote: > I know that's an unhappy idea but maybe it's time to include CMake > in stage3. Then it would be just a matter of temporarily enabling > bundled libs for stage builds, I guess. Not sure what's unhappy about it, but I like the idea, it will be painless for new users with rather limited cost of ownership on Gentoo side. -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
Hi, I'd like to bring the topic of defining default policy to do changes to packages within ::gentoo that one does not maintain. This topic goes back from time to time on #gentoo-dev, and as I was told, it was originally sent to gentoo-dev mailing list by robbat2 (I failed to find this in archive, so if anyone have copy of it, please share). Current policy is to never touch ebuild that one did not claim as maintainer unless maintainer of said package allowed you to do so. This is a bit unhealthy, especially when some developers that maintain packages are out of reach, or the patches to update ebuild just rot on the bugzilla and are not taken in by maintainers. What I'd like to end with would be to set a policy that allows any developer with write access to ebuilds tree do changes that are small in scope, like a minor bug fixes, adding missing flags, version bumps, anything, that does not require complete overhaul of ebuild, with the option to set in metadata.xml that policy for specified package is to deny anyone but maintainers from doing changes. The packages that would require a flag to prohibit non-maintainers from doing changes would of course be those of toolchain, or other big in user base packages that are in very good shape, as in gnome packages, kde packages, X11 packages and so on. Of course, the policy would also define, that if there are any bug introduced by changes that non-maintainer made, it's responsibility of those who did the change in first place to fix it and clean any mess that it has created. I personally am fine with others doing changes to packages I own, as long as they won't break anything and I do know from the discussion on #gentoo-dev, that there are others who have similar opinion about it. Those who feel territorial and those who believe only maintainers should maintain specified packages can just set the flag in metadata.xml and continue with the current state of things for their packages. The reason why I would like to get default policy to allow-all is that I do not believe most of developers would want to go around all the packages they own and set it manually to allow others doing changes even if they're fine with others touching those packages. What do you think folks? -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)
Hi, On 29/09/2019 11.56, Michał Górny wrote: > WDYT? You mean using HTTPS-only mirrors in 3rdparty mirrors? I am on board with that. Ideally, we would switch all of Gentoo resources to HTTPS too. I had a short discussion about it in #-infra where I was looking for distfiles and stage3 snapshots mirror roundrobin that is https enabled, this of course require a huge changes and it unlikely come anytime soon, but for what's it worth, I think no official Gentoo resource should default to non encrypted HTTP, and the only http enabled traffic should be a 301 HTTP redirect to https address. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dev-python/fabric up for grabs
On 11/05/2019 18.00, Virgil Dupras wrote: > Although I don't use it anymore because I find it too heavy for my > needs, Ansible is generally seen as a good replacement. FWIW Ansible does not seems that heavy when you realize that you can put a exec bit on a playbook, set shebang to ansible-playbook, set it to being a locally executed and define tasks within playbook itself, like: #!/usr/bin/env -S ansible-playbook -i localhost, - name: playbook gather_facts: false connection: local hosts: localhost tasks: - name: foo debug: msg: 'blah' Gets the job done really well. -- Piotr.
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] 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.
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
[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
