FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 05-17-2011, 01:13 AM
Duncan
 
Default 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
 
Old 05-17-2011, 03:47 AM
Michał Górny
 
Default 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 <ssuominen@gentoo.org> 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
 
Old 05-17-2011, 03:47 AM
Michał Górny
 
Default 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 <ssuominen@gentoo.org> 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
 
Old 05-17-2011, 04:33 AM
Christopher Head
 
Default 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 +0000 (UTC)
Duncan <1i5t5.duncan@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+pMACgkQXUF6hOTGP7e8EwCgkrW12lHNxJ Fov9HwP63CTZ+e
dwAAn2DOTWnkfMW9MT0GpKIeCabs2+7G
=HQoP
-----END PGP SIGNATURE-----
 
Old 05-17-2011, 05:23 AM
Canek Pelez Valds
 
Default 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.duncan@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 Pelez Valds
Posgrado en Ciencia e Ingeniera de la Computacin
Universidad Nacional Autnoma de Mxico
 
Old 05-17-2011, 07:28 AM
Alec Warner
 
Default 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 5:15 PM, Samuli Suominen <ssuominen@gentoo.org> 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-grouplugdev
> 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.

Does the handbook mention this?

>
>
> 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, ...)

As long as this is documented somewhere, I don't think users should
have to screw with anything too much to get this stuff working. God
knows I don't want to.

>
> 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.
>
>
 
Old 05-17-2011, 07:28 AM
Alec Warner
 
Default 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 5:15 PM, Samuli Suominen <ssuominen@gentoo.org> 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-grouplugdev
> 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.

Does the handbook mention this?

>
>
> 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, ...)

As long as this is documented somewhere, I don't think users should
have to screw with anything too much to get this stuff working. God
knows I don't want to.

>
> 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.
>
>
 
Old 05-17-2011, 12:50 PM
"Jorge Manuel B. S. Vicetto"
 
Default 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-grouplugdev
>> 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
zrw26lCyX6palAFxFfthueF7hT9ARsLdJSx8p9ERMS7BBrmjKk 8bnq20vm7kNcEC
mcohegWYr5cxe51YofMjPwRTbhpSZRJYrjYeUGYz6xZ9X85LlO N6UA6331KTcklb
v1qewoalKn4lCKykBmd2xAj1ok4VshX4MgxtZJsMJY+eqWITUo u6RYJfGOPYn/Hh
qvNLDoxdlyszJeD6aCi5xLK2tLTVEfVKO718jBz4EKOOk2jatw Di8ojRCUYHS+Mp
pBBdfvOivqgA1N1c9MOHf7z2vllVao5h/PckYJEwnff828SE6E9Ox/DdBbETBkfV
jDCwKmec65kSJ4bVcCtr0d2QZcUNq57GX1mrCoaPHKRSETiEW1 TCf4Fw2to0kbbo
t9x5Je+sAs4yAHMnD5u1mnQqkNjXkJ5MS9GFPyoTYQ1rux5zsS RNWSs50/ihKjL4
QtHafz/xYUIoCM4bQ2jIuf+ZOxVJ0SLPwaeYQGWZQOteLDhtqBI7UpWAP QNUoRYv
AxbgokNVwIcvhkjfi4iljKPPjD5jy5vlAUIPx1uanTIOE1ZdYs Yg8fO0OxOhAz5H
DS9b3xrXGednbBSuvsqygbnJKQQpD3r5ca4nXFz/1YjDOCq7OM0BjjzMRkaU0jk5
eGf9UkN3EHKkIm316Ges
=UGFI
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 08:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org