Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-05-2011 00:20, Samuli Suominen wrote: > On 05/17/2011 03:15 AM, Samuli Suominen wrote: >> Let's start with generalized example so everyone gets the idea... >> >> Reference: man 8 pklocalauthority >> >> /etc/polkit-1/localauthority/10-vendor.d/example-udisks.pkla >> >> [Local users] >> Identity=unix-group:plugdev >> Action=org.freedesktop.udisks.* >> ResultAny=yes >> ResultInactive=yes >> ResultActive=yes >> >> The above file would grant permission with or without active local >> ConsoleKit session to users in plugdev group to everything udisks handles. >> >> Notice that getting active ConsoleKit session you are now required to >> use PAM, or Display Manager like GDM with internal ConsoleKit support. >> >> Note that the PAM method requires you to have CONFIG_AUDITSYSCALL=y >> support enabled in kernel to get valid sessionid string and not all >> minor archs support this kernel option. >> >> >> We could have similar .pkla files also for other stuff like bluetooth, >> networkmanager, shutdown/reboot, suspend and hibernate (upower), and the >> list continues. >> >> The benefits are somewhat clear, things would work out of box for remote >> users beloging to right group, PAM-less users, as well as minor arches. >> >> The downside of this is that most users would propably end up using this >> as workaround for inactive ConsoleKit sessions that should really be >> local, but the user is just failing to configure his system in proper >> state to gain it (launching the X wrong way, wrong kernel opts, ...) >> >> And if we want this, should we stick to generalized plugdev group? >> >> Or perhaps group wheel for shutdown/reboot. Group storage for udisks. >> Group power for upower (hibernate, suspend). Group bluetooth for bluez. >> Group network for networkmanager?(Just throwing ideas...) >> >> So... any comments before I just pick what I think is best and commit >> the .pkla files (or not). I'm really 50-50 on this... >> >> Would like to get this decided before p.masking HAL. As others have already mentioned, I'd like to have the option to live without the *kit mess. One of the nice features about Linux, and Gentoo in particular, is being able to understand what's going on "under the hood" and the *kit movement seems to be about "magic" and "not bothering users" and not about being simple and clear. > Futhermore I would like the baselayout package to create the groups > decided here, be it wheel (already there), plugdev, or more fine grained > storage/power ones. > I think the "distribution policy" (be it the general consensus on this > thread) on this should be reflected in there. And it's the most > convinient place, then packages don't have to worry about creating > them... just follow About baselayout default users, we should split this topic to another thread as the releng team also needs something along these lines to get new stages with bl2 / openrc to build[1]. [1] - https://bugs.gentoo.org/show_bug.cgi?id=53269 - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN0m8GAAoJEC8ZTXQF1qEPpJsP/iMIo0RSFAEerpPH+6Mi+5QP zrw26lCyX6palAFxFfthueF7hT9ARsLdJSx8p9ERMS7BBrmjKk8bnq20vm7kNcEC mcohegWYr5cxe51YofMjPwRTbhpSZRJYrjYeUGYz6xZ9X85LlON6UA6331KTcklb v1qewoalKn4lCKykBmd2xAj1ok4VshX4MgxtZJsMJY+eqWITUou6RYJfGOPYn/Hh qvNLDoxdlyszJeD6aCi5xLK2tLTVEfVKO718jBz4EKOOk2jatwDi8ojRCUYHS+Mp pBBdfvOivqgA1N1c9MOHf7z2vllVao5h/PckYJEwnff828SE6E9Ox/DdBbETBkfV jDCwKmec65kSJ4bVcCtr0d2QZcUNq57GX1mrCoaPHKRSETiEW1TCf4Fw2to0kbbo t9x5Je+sAs4yAHMnD5u1mnQqkNjXkJ5MS9GFPyoTYQ1rux5zsSRNWSs50/ihKjL4 QtHafz/xYUIoCM4bQ2jIuf+ZOxVJ0SLPwaeYQGWZQOteLDhtqBI7UpWAPQNUoRYv AxbgokNVwIcvhkjfi4iljKPPjD5jy5vlAUIPx1uanTIOE1ZdYsYg8fO0OxOhAz5H DS9b3xrXGednbBSuvsqygbnJKQQpD3r5ca4nXFz/1YjDOCq7OM0BjjzMRkaU0jk5 eGf9UkN3EHKkIm316Ges =UGFI -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
On Mon, May 16, 2011 at 8:13 PM, Duncan <1i5t5.dun...@cox.net> wrote:
[...]
> User perspective...
For the sake of having a user with a different point of view, let me
say that I firmly believe the new *kit daemons (along things like
pulseaudio, systemd, GNOME 3, KDE 4) are the future, and Gentoo should
drop support for older technologies as soon as possible. Emphasis in
"as soon as possible", not "today".
The groups model was good, 40 years ago. But it's restrictive (a group
gets all or nothing), inflexible, and it difficults the implementation
of nice GUIs that take care of them. And it's not only my point of
view: the people in the kernel, in freedesktop, and in GNOME and KDE
think similarly, and that's why this pletora of new *kit programs (and
related new technologies) are becoming mandatory to run not only
desktop workstations, but also servers and embeded systems.
And actually that's the most powerful reason for Gentoo to drop
support for the older technologies: The people who actually *writes*
the code are starting to drop support for them.
We should embrace the new technologies. Sure, sometimes a new
technology would turn out to be a mistake (HAL), or it would take a
while to get really good (pulseaudio, ALSA replacing OSS). But when
they finally get "there", it's worth every step of the way.
Of course they can take a while to get "there", and that's why I'm
saying that the support must be dropped "as soon as possible", not
"today". But eventualy said support must be dropped: The maintainers
of the code would not support it, so I don't see a reason to waste the
Gentoo developers time doing it.
I know a lot of people would be 100% against what I'm saying, and they
will be very vocal about it. But I just want to leave note that there
are people like me who actually want to embrace this new technologies,
and that we are willing to do the testing and suffer the pains of
trying the new technologies.
And I say this as a user of Unix since 1996, and writing this email in
my laptop running Gentoo with the systemd and GNOME 3 overlays
installed at the same time, and loving how the shape of the future
looks like.
Just my ${CURRENCY/100}.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 17 May 2011 01:13:15 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > User perspective... > > If it's at all possible to continue to have a consolekit/polkit-less > system, making them USE-based dependencies of kde, gnome, etc, > relying entirely on apparently now legacy groups, that should be > done. Given upstream dependencies it might not be possible, or might > require "dummy" libraries/services that simply return permitted for > whatever and let kernel user and group permissions handle it, but > having such dummy services is still a good thing, and /shouldn't/ be > too hard to maintain, given most functionality would be stubbed in. (I'm only a user, not a developer, but…) I agree with this. I don't use the various *kits. Don't have any use for them. I just throw myself in plugdev and I'm happy with that solution, and I'd appreciate being able to keep on doing that. Of course if it becomes impossible to support then it's not reasonable for distro maintainers to do that, but as long as it works I'd appreciate having the choice. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk3R+pMACgkQXUF6hOTGP7e8EwCgkrW12lHNxJFov9HwP63CTZ+e dwAAn2DOTWnkfMW9MT0GpKIeCabs2+7G =HQoP -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
On Tue, 17 May 2011 03:20:40 +0300 Samuli Suominen wrote: > Futhermore I would like the baselayout package to create the groups > decided here, be it wheel (already there), plugdev, or more fine > grained storage/power ones. Just my .03 PLN -- I'd like to remind you that 'plugdev' group is also used in at least a few HAL/StorageKit-independent packages. I don't think it's a good idea to rename this group now. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
Samuli Suominen posted on Tue, 17 May 2011 03:20:40 +0300 as excerpted: > On 05/17/2011 03:15 AM, Samuli Suominen wrote: >> The above file would grant permission with or without active local >> ConsoleKit session to users in plugdev group to everything udisks >> handles. >> >> Notice that getting active ConsoleKit session you are now required to >> use PAM, or Display Manager like GDM with internal ConsoleKit support. >> >> Note that the PAM method requires you to have CONFIG_AUDITSYSCALL=y >> support enabled in kernel to get valid sessionid string and not all >> minor archs support this kernel option. User perspective... If it's at all possible to continue to have a consolekit/polkit-less system, making them USE-based dependencies of kde, gnome, etc, relying entirely on apparently now legacy groups, that should be done. Given upstream dependencies it might not be possible, or might require "dummy" libraries/services that simply return permitted for whatever and let kernel user and group permissions handle it, but having such dummy services is still a good thing, and /shouldn't/ be too hard to maintain, given most functionality would be stubbed in. I still remember the bad old days of the console pam module fighting with udev, etc, over permissions, and don't want to relive it. Having clear and simple group options that "just work" even when *kit is misconfigured or broken or not existing at all on a system is a valuable feature that IMO shouldn't be removed lightly. But "nice" doesn't mean it's actually available from upstreams, and I'm not in a position to maintain such a package, so... >> We could have similar .pkla files also for other stuff like bluetooth, >> networkmanager, shutdown/reboot, suspend and hibernate (upower), and >> the list continues. You mention having baselayout setup the groups, below. It's unclear, however, to which package these files should belong. Baselayout also (perhaps USE flag controlled)? The individual services? A separate package pulled in as a dependency where necessary? Note that as you describe these files, or at least as I envision them, they'd be much like logrotate files or the like -- they could be installed (to a non-active/sample location) by default, then copied/moved by the user to the appropriate location to activate. So baselayout or a separate package could install the whole batch and let the user activate-by-moving individual files into place as desired. >> The benefits are somewhat clear, things would work out of box for >> remote users beloging to right group, PAM-less users, as well as minor >> arches. >> >> The downside of this is that most users would propably end up using >> this as workaround for inactive ConsoleKit sessions that should really >> be local, but the user is just failing to configure his system in >> proper state to gain it (launching the X wrong way, wrong kernel opts, >> ...) >> >> And if we want this, should we stick to generalized plugdev group? >> >> Or perhaps group wheel for shutdown/reboot. Group storage for udisks. >> Group power for upower (hibernate, suspend). Group bluetooth for >> bluez. Group network for networkmanager?(Just throwing ideas...) >> >> So... any comments before I just pick what I think is best and commit >> the .pkla files (or not). I'm really 50-50 on this... I like the idea of separate groups. But I don't see a practical difference between allowing suspend/hibernate and shutdown/reboot, so that could be the same one. But preferably use power, not wheel. Just because I want my user to be able to suspend/hibernate/shutdown/reboot doesn't mean I want to give him the other privs (su...) associated with wheel. I do really like the idea of separating power from storage from network from bluez, tho. =:^) >> Would like to get this decided before p.masking HAL. HAL... the devil's spawn! How many, admins and devs alike, will be glad to see it be a fading memory like that console pam module?! > Futhermore I would like the baselayout package to create the groups > decided here, be it wheel (already there), plugdev, or more fine grained > storage/power ones. As above, the groups, but what about the files? > I think the "distribution policy" (be it the general consensus on this > thread) on this should be reflected in there. And it's the most > convinient place, then packages don't have to worry about creating > them... just follow No disagreement there. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
On 05/17/2011 03:15 AM, Samuli Suominen wrote: > Let's start with generalized example so everyone gets the idea... > > Reference: man 8 pklocalauthority > > /etc/polkit-1/localauthority/10-vendor.d/example-udisks.pkla > > [Local users] > Identity=unix-group:plugdev > Action=org.freedesktop.udisks.* > ResultAny=yes > ResultInactive=yes > ResultActive=yes > > The above file would grant permission with or without active local > ConsoleKit session to users in plugdev group to everything udisks handles. > > Notice that getting active ConsoleKit session you are now required to > use PAM, or Display Manager like GDM with internal ConsoleKit support. > > Note that the PAM method requires you to have CONFIG_AUDITSYSCALL=y > support enabled in kernel to get valid sessionid string and not all > minor archs support this kernel option. > > > We could have similar .pkla files also for other stuff like bluetooth, > networkmanager, shutdown/reboot, suspend and hibernate (upower), and the > list continues. > > The benefits are somewhat clear, things would work out of box for remote > users beloging to right group, PAM-less users, as well as minor arches. > > The downside of this is that most users would propably end up using this > as workaround for inactive ConsoleKit sessions that should really be > local, but the user is just failing to configure his system in proper > state to gain it (launching the X wrong way, wrong kernel opts, ...) > > And if we want this, should we stick to generalized plugdev group? > > Or perhaps group wheel for shutdown/reboot. Group storage for udisks. > Group power for upower (hibernate, suspend). Group bluetooth for bluez. > Group network for networkmanager?(Just throwing ideas...) > > So... any comments before I just pick what I think is best and commit > the .pkla files (or not). I'm really 50-50 on this... > > Would like to get this decided before p.masking HAL. ... Futhermore I would like the baselayout package to create the groups decided here, be it wheel (already there), plugdev, or more fine grained storage/power ones. I think the "distribution policy" (be it the general consensus on this thread) on this should be reflected in there. And it's the most convinient place, then packages don't have to worry about creating them... just follow
