PolicyKit confusion

Da Rock freebsd-questions at herveybayaustralia.com.au
Fri Dec 23 15:30:33 UTC 2011

On 12/24/11 00:22, Roland Smith wrote:
> On Fri, Dec 23, 2011 at 02:18:19PM +1000, Da Rock wrote:
>> This is doing my head in.
> :-)
>> I'm trying to get my head around hal, dbus,
>> and PolicyKit, and I've made some inroads on the basics, but I cannot
>> get a few things happening.
>> One: I managed to get network:/// smb shares working in say nautilus
>> (not that I've specifically mounted one- not a windows in sight here
>> thank god!), but I was hoping for NFS shares to show up.
> Why not just use mount_nfs from your login shell's rc file?
I'm dealing with mobile devices (laptops, etc), ergo I need an automount 
solution. I've been using automounter happily for removable devices, but 
users are picky and I then can't use amd for nfs and automounter 
couldn't give a shit about network drives. One scenario is network goes 
down and I get a screenful of error messages- it annoys the shit out of 
me, let alone scaring illiterate users.

I did come across one interesting observation in my search for the 
truth: its easier to mount a winblows share than an nfs one! On any *nix 
no less...
>> I also got the
>> usb disk to show up as a 'place' but when I access it I get permissions
>> issues. This is what I'm hung up on.
> I'm not using policykit or hal, but I did make a separate group predictably
> called 'usb' to solve permission problems for USB devices. My user-id is a
> member of that group. I have to following set in /etc/devfs.rules:
> [my_devs=10]
> add path 'da*' mode 0660 group usb
> add path 'msdosfs/*' mode 0660 group usb
> add path 'usb/*' mode 0660 group usb
> add path 'ugen*' mode 0660 group usb
> add path 'tap*' mode 0660 group wheel
> add path 'pass*' mode 0660 group cdrom
> add path 'dri/card*' mode 0666
> And in /etc/rc.conf I have activated this ruleset:
> devfs_system_ruleset="my_devs"
> With this I can access the necessary devices.
Already done, but that doesn't help automounting.
>> I checked out /media/hal-* and I see that the mount occurs only as root.
>> How do I change that exactly? I need it showing for operator group.
> Is hald running under its own user-id? Try the usb group thing and add the hald
> user to that group.
Interesting theory, but it doesn't hold water. More further...
>> I've
>> searched high and low and googled my brains out, but anything remotely
>> related is for linux and udev.
> I don't think enough people care to make it really work under FreeBSD. I've
> certainly never missed it.
They don't care too much under linux either.... So many years, yet not a 
single user doc anywhere on any of the f***ing monsters! Goddamn linux 
devs- ever heard of KISS?! How about a user doc for something so bloody 
confusing it takes a brain surgeon to figure it out?

Ok. The final cut... I did finally get hal/polkit/dbus to cooperate in 
the end. But there were more suspects by the end:

exec xhost +localhost &
## test for an existing bus daemon, just to be safe
if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
     ## if not found, launch a new one
     eval 'dbus-launch --sh-syntax --exit-with-session'
     echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS"
exec /usr/local/libexec/polkit-gnome-authentication-agent-1 &
exec xscreensaver &
exec ck-launch-session icewm-session

So... one needs to start a local dbus session, a polkit-auth session, 
and a ck-launch-session...

And in PolicyKit.conf (I'm not entirely happy with the security here), 
scratch user or group matches and just add the action with result=yes.

Now that will work in a single user situation. There is yet another 
culprit here: gconf. GConf was the shooter on the grassy knoll causing 
issues with the mount options and permissions.

And the crazy part in all this is there is hardly a scratch of info out 
there on such complex software that are supposedly interacting together 
in some way that is not exactly documented and yet is in control of the 
whole bloody system! We should just all revert to winblows at this rate- 
there's more docs there than for this stuff! An absolute embarrassment 
to the FOSS community...

Ahh, one more thing of note here: polkit-gnome-authorization would not 
work under any circumstances (run as root or otherwise) to change 
policies! WTF!
> You might take a look at devd(8) as a FreeBSD alternative, but I'm not sure if
> it notices new da devices popping up.
Oh, believe me I'd happily jump on it rather than deal with this mess. 
But I can't find anything that will interact happily with the apps, 
mount network shares of all kinds, and be exceedingly user friendly 
(take note lin-devs: user-friendly != sys_admin-hell at least it 
_doesn't have to_).

How forgiving is devd to a user pulling the plug to early? I did look 
into it a bit, but it appeared nearly as difficult as deciphering the 
above scenario- that said, having come through the other side of that 
I'm not so sure my judgment was very accurate :) So now I might check 
that fork out and see...

God! What a mess... this belongs in the X-files: the truth _is_ out 
there. But you might lose your head and many years of life just finding 
the fragments!

HTH someone now when the whole lot will change yet again and this will 
probably be pointless...

More information about the freebsd-questions mailing list