On Mon, May 16, 2011 at 5:15 PM, Samuli Suominen <ssuominen@g.o> 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.
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.
>
>
|
