On Mon, May 18, 2009 at 05:05:09AM -0500, David C. Rankin, J.D.,P.E. wrote:

When I stick the card in, as my normal user I can't access the device shown under "Services" "Storage Media" and there is no "disk" entry in /media.

I usually have to refresh the window (F5) to make removable devices appear in system:/media inside kdemod3 konqueror, regardless of the hal/policykit mount problems.

       Thanks. But in this case with kdemod3 the card shows up in system:/media (or what I've been calling media:/ [not /media]) my card appears instantly and disappears as soon as I remove it. So I dunno, there is something else going on here. I'll find it, but if anyone else has a clue, please pass it along.

AFAIK, HAL doesn't mount/umount devices .. hal just notifies your DE (or whatever listens to its dbus signals) and then your DE makes a request for the device to be mounted or not (based on preference this could be automatic or manual). -- damjan

On or about Monday 18 May 2009 at approximately 09:48:00 David Rosenstrauch composed:

David C. Rankin, J.D.,P.E. wrote:

...

On or about Sunday 17 May 2009 at approximately 03:51:10 David C. Rankin,

...

Another interesting note. When I inserted the card, there was no entry created in /media. Now 10 minutes later after I have been copying the photos, etc., the mount of /dev/mmcblk0p1 has *appeared* mounted on /media/disk? Huh?

I can't tell you when it appeared, but I can tell you that for at least 4-5 minutes. So why the initial error and why the magical appearance after the error telling me it wasn't going to be mounted? What to check for more info?

Here is the deal,

When I stick the card in, as my normal user I can't access the device shown under "Services" "Storage Media" and there is no "disk" entry in /media.

If I start konqueror running as root and then access "Services" "Storage Media" and the SD card (/dev/mmcblk0p1 in this case), Presto the device automatically appears as "disk" under /media and then I *can* access it (rw) as my normal user. What gives? What permissions are stuck?

Short answer:

Use this for your /etc/PolicyKit/PolicyKit.conf:

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->

<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN" "http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">

<!-- See the manual page PolicyKit.conf(5) for file format -->

<config version="0.1"> <!-- <define_admin_auth group="wheel"/> --> <match action="org.freedesktop.hal.storage.mount-removable"> <return result="yes"/> </match> <!-- <match action="org.freedesktop.hal.storage.eject-removable"> <return result="yes"/> </match> --> </config>

Long answer:

See: http://bbs.archlinux.org/viewtopic.php?pid=542472

I have to say, I'm not very fond of this new console-kit/policy-kit stuff being the default in hal now. I far prefer the simplicity of standard unix groups and permissions.

DR

DR, thanks! I guess I'll like Policy Kit once I make friends with it, but it sure was a whole lot easier just issuing the 'mount /dev/whatever /media/whatever' command. It looks like I just didn't have enough in PolicyKit.conf. I had the following: <?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- --> <!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN" "http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd"> <!-- See the manual page PolicyKit.conf(5) for file format --> <config version="0.1"> <match action="org.freedesktop.hal.storage.mount-removable"> <match group="users"> <return result="yes"/> </match> </match> <match user="david"> <return result="yes"/> </match> <match user="david"> <!-- replace with your login or delete the line if you want to allow all users to manipulate devices (keep security issues in mind though) --> <match action="org.freedesktop.hal.storage.*"> <return result="yes"/> </match> <match action="hal-storage-mount-fixed-extra-options"> <!-- for internal devices mounted with extra options like a wished mount point --> <return result="yes" /> </match> <match action="hal-storage-mount-removable-extra-options"> <!-- for external devices mounted with extra options like a wished mount point --> <return result="yes" /> </match> </match> <!-- don't forget to delete this line if you deleted the first one --> </config> Why in the heck the following wasn't good enough escapes me at present: <match user="david"> <return result="yes"/> </match> That's says let *me* do anything with anything (twice I might add). I guess in addition to giving yourself global authorization you also have to give yourself specific authorization as well. Also, why do you have .eject-removable commented out? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On or about Monday 18 May 2009 at approximately 12:42:41 David Rosenstrauch composed:

BTW, maybe it's not sufficient to restart hal, since theis isn't technically a HAL file, but rather a policy kit file. So I'd suggest logging out and then in again after the change.

HTH,

DR

Well, I guess that would be yet another bug in PolicyKit. Per the PolicyKit.conf man page: <quote> Changes to this configuration file are immediately propagated to running processes using the PolicyKit library. If the configuration file is invalid, processes using this library will log this fact to the system logger and the library will only only return no as the answer to processes using it. </quote> Of all the changes I've made, no errors logged so it should be happily propagating, ... or fornicating, ... or whatever PolicyKit does to my system ;-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On or about Tuesday 19 May 2009 at approximately 03:33:03 bardo composed:

2009/5/18 David C. Rankin, J.D.,P.E. :

...

               <match group="users">                        <return result="yes"/>                </match>

I think this may be your problem. I searched some time ago and found out PolicyKit didn't support group matches. A quick look to the PolicyKit.conf(5) man page seems to confirm this is still the case. Now, I don't know if an invalid entry could invalidate the whole config, but it's worth a try.

Corrado

Corrado, You and I may be saying the same thing for two different circumstances. Admin_auth certainly allows both user and group auths for actions (man 5 PolicyKit.conf): define_admin_auth This element is used to specify the meaning of "authenticate as administrator". It is normally used at the top-level but can also be used deep inside a number of match elements for conditional behavior. There can only be a single attribute in each define_admin_auth element. POSIX Extended Regular Expression syntax is not supported in the value part, however multiple values to match on can be separated with the bar (|) character. The following attributes are supported: user Administrator authentication means authenticate as the given user(s). If no define_admin_auth element is given, the default is to use user="root" e.g. administrator authentication mean authenticate as the super user. group Administrator authentication means that any user in the groups matching the given value can be used to authenticate. Typically, on a system with the root account disabled one wants to use something like group="wheel" to e.g. enable all UNIX users in the UNIX group wheel to be able to authentication whenever administrator authentication is required. </quote> The strange thing is that I can specify myself or the wheel group as an admin with auth privileges and policy kit still doesn't allow access. I haven't had time to play with it anymore yet after DR sent his config over, but I'll let you know. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On or about Wednesday 20 May 2009 at approximately 04:00:48 am bardo composed:

2009/5/20 David C. Rankin, J.D.,P.E. :

...

On or about Tuesday 19 May 2009 at approximately 03:33:03 bardo composed:

...

2009/5/18 David C. Rankin, J.D.,P.E. :

...

               <match group="users">                        <return result="yes"/>                </match>

I think this may be your problem. I searched some time ago and found out PolicyKit didn't support group matches. A quick look to the PolicyKit.conf(5) man page seems to confirm this is still the case. Now, I don't know if an invalid entry could invalidate the whole config, but it's worth a try.

Corrado

Corrado,

  You and I may be saying the same thing for two different circumstances. Admin_auth certainly allows both user and group auths for actions (man 5 PolicyKit.conf):

define_admin_auth

I wasn't saying you can't use "group" as an attribute for "define_admin_auth", I was saying you can't use it as an attribute for "match". So at least that rule won't work, I tried it before. Now, I don't know how PolicyKit deals with wrong parameters, but in the worst case it could treat the whole file as invalid, and that could be why your *other* rules don't work.

I hope I made myself clearer this time :)

Corrado

Yep, I'll give Policy kit another shot when I pop the archlinux drive back in. If Policy Kit is ignoring the whole file (which it shouldn't do, but seems like it is), then that should be logged somewhere. I have been through everything.log and messages.log, etc. and there isn't any message like that. If it isn't logging rejections, then we need to find a way to have it do so. It would sure make troubleshooting policy kit problems a whole lot easier. Thank you for your help.

On or about Monday 18 May 2009 at approximately 09:48:00 David Rosenstrauch composed:

         <match action="org.freedesktop.hal.storage.mount-removable">                  <return result="yes"/>          </match> <!--          <match action="org.freedesktop.hal.storage.eject-removable">                  <return result="yes"/>          </match> -->

What I don't get is this (from PolicyKit(5)): ALLOW EVERYTHING The users "davidz" and "bateman" are allowed to do any action: <match user="davidz|bateman"> <return result="yes"/> </match> I have: <match user="david"> <return result="yes"/> </match> I'm david, so what in the heck is the problem :-( -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com