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, 12:15 AM
Samuli Suominen
 
Default RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?

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.
 
Old 05-17-2011, 12:20 AM
Samuli Suominen
 
Default 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-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.

...

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
 

Thread Tools




All times are GMT. The time now is 07:33 PM.

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