By Adam Williamson at http://www.happyassassin.net
Well, I woke up this morning and the site wasn’t working, which isn’t good! So I did a quick fix (gave it an extra 128MB of RAM in VMware and turned on wp-super-cache) and started looking into hosting options. That’s going to be a fun area to get into. Sigh. Still, seems to be holding up so far.
After that I did the forums, and took care of things arising from there. I backported the latest x11-driver-video-intel to 2008 Spring as well (after doing it for 2009, see yesterday). Prompted by this thread, I took a deeper look at what the heck PolicyKit does, exactly, and what’s going wrong in this case, which has been reported by several people.
The symptom is that, if you have a partition on an internal drive that isn’t automatically mounted at boot, it will be shown in Dolphin’s sidebar, but trying to click on it will give you an error message at the bottom of the Dolphin window, saying: “An error occurred while accessing ‘(thepartition)’. the system responded: org.freedesktop.Hal.Device.PermissionDeniedByPolicy: org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always <-- (action, result)"
Cryptic, much? :)
Well, here's what's going on here. PolicyKit is essentially a generic system for restricting access to actions by users. It lets developers specify that a certain action can only be performed by certain users, or only with admin privileges, or only when a user is active, or only when a user is logged in to a local console, or a combination of the above (for instance, only the user adamw can perform the action, and only when he's logged in locally). Technically speaking PolicyKit has all sorts of advantages over the old, rather hackish frameworks like 'just run stuff as root via gksu or kdesu', console-helper, and things like that. Firstly, it's much more fine-grained, and secondly, it separates out the actual actions that require raised privileges. So it allows, say, a partition management application to be run by a regular user, and then ask for root privileges only if it needs them to alter the partition table. And only that specific action would be done with root privileges: the rest of the application continues to run unprivileged. This has obvious big security benefits over running the entire thing as root.
So, PolicyKit is shiny and useful. But, in this case, it's tripping us up. Why? Well, let's look at the message in more detail:
org.freedesktop.Hal.Device.PermissionDeniedByPolicy: org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always
PermissionDeniedByPolicy is why it won’t mount: it’s telling us PolicyKit isn’t letting us. What ultimately happened is Dolphin asked HAL to mount the device, and it refused, because HAL is now integrated with PolicyKit. Why doesn’t it let us? Well, org.freedesktop.hal.storage.mount-fixed is the specific PolicyKit ‘action’ that’s failing here. That’s the action for mounting a fixed storage device - that is, a permanent storage device, like an internal hard disk partition. The counterpart is a removable storage device, like a USB key. And, finally, auth_admin_keep_always is the access policy granted to the current user. What auth_admin_keep_always means is ‘allow this user to perform the action, but only after authenticating for admin privileges. But once the user has authenticated once, remember that authentication for the rest of this session.’
So, PolicyKit is set to allow regular users to mount fixed partitions, but only if they give the root password first. Why does Dolphin just fall over, instead of asking for the root password? That would be because Dolphin does not, yet, have PolicyKit integration - so it doesn’t know that, in this case, it should call the helper provided by PolicyKit-kde to ask the user to authenticate as root. Since it doesn’t do that, PolicyKit knows the root authentication wasn’t performed, and refuses permission to mount the partition.
So THAT is why you can’t mount an internal drive partition via Dolphin in KDE 4 on Mandriva 2009 (and any other distribution where this is PolicyKit’s default configuration). Whew. What’s to be done?
I filed a bug with KDE about this issue. It has been accepted by one of the lead Dolphin developers, Peter Penz, so hopefully it will be worked on and we’ll be able to integrate this into Dolphin before 2009 Spring comes out. I let our KDE team know about the issue, so they can monitor it. If integration for Dolphin is not forthcoming, we could adjust the default policy in KDE to allow users to mount partitions without authentication, but of course that would be rather less secure.
What can you do if you’re annoyed by this bug (or a similar one) and can’t wait for a fix (or a new distribution release) to show up? Change the policy, of course! There are two GUI frontends for PolicyKit: policykit-gnome and policykit-kde. The policykit-kde shipped in 2009 was rather broken. However, as part of my investigation of this issue, I realized that problem, and updated the Cooker package to the latest SVN revision, which works a lot better. So I’ve also sent that package to 2009 /contrib/backports. I haven’t tested it on 2009, but it ought to work okay, the PolicyKit API is quite stable. So, install that package, and run the KDE Control Center. Go to the Advanced tab, and click on PolicyKit Authorization. Here, you can see all the different sets of actions which PolicyKit controls access to. The one we’re interested in is org.freedesktop.hal, so expand that entry.
Click on “Mount file systems from internal drives.” You’ll see, underneath, the real action name, which we saw in the error message earlier: org.freedesktop.hal.storage.mount-fixed. In theory you should be able to just set the Anyone: drop-down box to Yes, but that didn’t work for me: I think there’s an issue with the resolution of user names. So, instead, create an explicit authorization. Click the ‘Grant’ button, next to Explicit Authorizations. Check the ‘Show system users’ box (this shouldn’t be necessary, and I think it’s related to the ‘Anyone’ bug), and then select your username from the drop-down box (mine was right at the bottom). You can set a constraint, or not, as you choose (it’s probably safest to set ‘Must be in active session on local console’). Then click ‘Grant’. Now you can quit the Control Center, run Dolphin, and click on your partition - and it should mount. There, wasn’t that simple?!
PolicyKit is actually developing into a very powerful framework and will likely be used extensively by many applications in future, and you will be able to use it as a very sophisticated lockdown tool to control how much access users have to different actions on your system.
After that, I also bumped the kde4-extragear-sysadmin package I maintain (which provides the kiosktool and partitionmanager apps, for KDE 4) to the latest SVN, since this whole PolicyKit thing reminded me about it. I also sent Isomaster 1.3.5 to /contrib/backports for 2008 Spring and 2009; thanks to Jerome Soyer for doing the version bump.
Finally, I worked on packaging Navit, a driving navigation application, which was requested by Adam Pigg. With a few patches here and there I’ve got it properly built, but it’s got a bit of an ugly system for configuration (you have to hand-edit a .xml file) and, despite downloading and plugging in a Canadian map file, I couldn’t get it to display anything but a blank orange screen. I’m not sure if this is related to my lack of a GPS device, or just Cooker weirdness, or something else. So I sent the current package to Adam to see whether he can get the app going, since he really has a GPS system. If we can get it going, it’ll be uploaded to Cooker, 2009 and 2008 Spring.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment