Description of problem: If you have a partition encrypted with cryptsetup-luks dolphin is unable to mount it. It asks for passphrase but then shows an error message in the bottom of the window: An error occured while accessing 'Volume (crypto_LUKS)', the system said: org.freedesktop.Hal.Device.PermissionDeniedByPolicy: org.freedesktop.hal.storage.crypto-setup-fixed auth_admin_keep_always <--(action, result) This message is even shown if the entered passphrase is wrong. Version-Release number of selected component (if applicable): kdebase--4.0.0-2.fc9 How reproducible: ever Steps to Reproduce: 1. if not exists encrypt a volume with cryptsetup-luks 2. start dolphin and single-click on the volume in the left panel 3. enter passphrase Actual results: dolphin don't mount volume Expected results: dolphin mount volume properly Additional info: "mount.crypt /dev/sdX <Mountpoint>" (from package pam_mount) is working as root. Also mounting in dolphin as root is working.
Another PolicyKit-related issue... davidz: Do you have any idea what's going wrong here?
Sorry, let's keep the component at kdebase until we know what's really at fault.
This is because KDE apparently lacks PolicyKit support; I'd ask KDE upstream to include this; HAL has shipped with (working) PolicyKit support since Oct 2007 and it's been known since summer 2007 that it would be this way. Anyway, the hint is this org.freedesktop.Hal.Device.PermissionDeniedByPolicy: "org.freedesktop.hal.storage.crypto-setup-fixed auth_admin_keep_always <--(action, result)" The program calling into HAL needs to acquire an authorization by using a PolicyKit Authentication Agent. It's explained here http://hal.freedesktop.org/docs/PolicyKit/model-theory-of-operation.html Granted, it sounds a lot more complicated than it is; it basically amount to the caller (I guess dolphin in this case) calling, via the D-Bus session bus, into the standardized interface http://hal.freedesktop.org/docs/PolicyKit/model-authentication-agent.html e.g. the org.freedesktop.PolicyKit.AuthenticationAgent service on the _session_ bus (emphasis on session since HAL lives on the system bus). Basically, you just take the first word out of the error messsage, this one "org.freedesktop.hal.storage.crypto-setup-fixed" and do the moral equivalent of $ dbus-send --print-reply --session --dest=org.freedesktop.PolicyKit.AuthenticationAgent / org.freedesktop.PolicyKit.AuthenticationAgent.ObtainAuthorization string:org.freedesktop.hal.storage.crypto-setup-fixed uint32:0 uint32:$PPID from the code. To be hundred percent correct you also take out the second word and run it through polkit_result_from_string_representation() and check that the returned value isn't POLKIT_RESULT_NO or POLKIT_RESULT_UNKNOWN. I'm unaware of any native KDE PolicyKit authentication agent other than someone from Pardus starting to write one http://lists.freedesktop.org/archives/dbus/2007-November/008882.html Might be good to ask him what's up (if you find out please let me know). In the mean time you can use the authorization agent available in the PolicyKit-gnome package; it looks like this http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html Sorry about creating this additional amount of work for the Fedora KDE team but I guess it's like this when things move fast...
Well. Is it really a kde problem? gnome-mount gives me the same error (this time for a normal partition and started from a kde session and from tty1): [testuser@localhost ~]$ gnome-mount -t -d /dev/sdb5 gnome-mount 0.7 ** (gnome-mount:3610): WARNING **: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_45059444_f164_46fe_8221_5f70b45eb7ac org.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always <-- (action, result)
The problem, as I understand it from David's explanation, is that the policy is to pop up a dialog asking what to do, but PolicyKit-gnome appears not to be running, so PolicyKit can only decide to default to denying.
(In reply to comment #4) > Well. Is it really a kde problem? gnome-mount gives me the same error (this > time for a normal partition and started from a kde session and from tty1): > > [testuser@localhost ~]$ gnome-mount -t -d /dev/sdb5 > gnome-mount 0.7 > > ** (gnome-mount:3610): WARNING **: Mount failed > for /org/freedesktop/Hal/devices/volume_uuid_45059444_f164_46fe_8221_5f70b45eb7ac > org.freedesktop.Hal.Device.PermissionDeniedByPolicy : > org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always <-- (action, > result) Try without '-t'. If that doesn't work it's not unlikely I need to fix gnome-mount for this too. Thanks for the heads-up. (In reply to comment #5) > The problem, as I understand it from David's explanation, is that the policy is > to pop up a dialog asking what to do, but PolicyKit-gnome appears not to be > running, so PolicyKit can only decide to default to denying. PolicyKit-gnome is activated on demand and nothing will pop up automatically. As I said in comment 3 you need to patch the program that calls Mount() on HAL to properly deal with the org.freedesktop.Hal.Device.PermissionDeniedByPolicy exception.
Btw, how does KDE / Dolphin etc. handle mounting fixed partitions in the first place? That requires PolicyKit support as well, e.g. # polkit-action --action org.freedesktop.hal.storage.mount-fixed action_id: org.freedesktop.hal.storage.mount-fixed description: Mount file systems from internal drives. message: System policy prevents mounting internal media default_any: no default_inactive: no default_active: auth_admin_keep_always Once you clear org.freedesktop.hal.storage.crypto-setup-fixed you will run into handling policy for this thing too for org.freedesktop.hal.storage.mount-fixed. (Oh, I see, that's the problem in comment 5 (so removing -t will definitely work there)).
Kubuntu appears to be using a hack where, due to lack of PolicyKit integration, they're just hardcoding the password prompt dialog and the privilege elevation code (they use kdesudo if available, kdesu otherwise, we can probably omit the kdesudo part in Fedora): http://patches.ubuntu.com/k/kdebase/extracted/kubuntu_9915_userdiskmount.diff It also contains a fix/workaround for bug 378041 (it tells kdebase not to pass HAL the options it doesn't like).
(Please note that the Kubuntu patch is against KDE 3 and will probably have to be ported to apply to KDE 4.)
We cannot backport this as KDE 4 uses a completely different API (media vs. Solid). I'll try to create a patch to support PolicyKit in Solid in the next few days
The code is completely different, but the general ideas from the patch can be used.
Created attachment 298357 [details] Untested port of the PermissionDeniedByPolicy part of the Kubuntu patch This is my first attempt at porting/rewriting the Kubuntu patch for KDE 4: * straight off the presses, may or may not compile, completely untested. * The "omit uid= if NTFS" (a.k.a. bug 378041) hack from the Kubuntu patch is not included in this version. Note: an important restriction to keep in mind if you want to modify that patch is that libsolid does NOT link against libkdecore, so only Qt-only stuff can be used, no KStandardDirs, i18n etc. By the way, IMHO we should also apply kubuntu_9915_userdiskmount.diff to our F8 KDE 3 packages, as this issue is likely to affect KDE 3 too and bug 378041 (which that patch also fixes) was even actually reported against KDE 3.
Created attachment 298359 [details] Untested port of the Kubuntu patch Updated patch: * added workaround for bug 378041 (IMHO still clearly a HAL bug), * using explicit QString::fromLatin1 to convert string literals to QString.
the workaround ist included in kdelibs-4.0.2-12.fc9. Sebastian, couls you please try again with the new version? thanks
Seems to work for USB devices and DVDs now. But in a short test I was unable to mount a cryptsetup-luks encrypted partition. The password dialog is shown, but the password not acceptet. I'll try to get some more informations about that.
Uh, USB devices and DVDs aren't supposed to require a root password at all...
(In reply to comment #16) > Uh, USB devices and DVDs aren't supposed to require a root password at all... Not the root password, the password for the encrypted partition. DVD and USB are working without entering a password.
But weren't they before? All this patch fixes is: * prompts for the root password when PolicyKit denies permission to the user, * NTFS partitions.
(In reply to comment #18) > But weren't they before? I've started the bug because I got an PolicyKit refuse error when trying to mount encrypted partitions. But also normal ext3 partitions weren't mountable if they are not listed in fstab. > All this patch fixes is: > * prompts for the root password when PolicyKit denies permission to the user, With kdelibs-4.0.3-1.fc9.i386 this seems to work correctly now. > * NTFS partitions. Indeed. NTFS and VFAT-Partitions (here: a NTFS partition on a USB-HDD) is now working. Ext3 partitions are still denied.