[blfs-support] Automounting

David Brodie lfs at aba.eclipse.co.uk
Tue Dec 10 12:34:27 PST 2013

On 10/12/13 17:59, Dan McGhee wrote:
> I wrote that rule, but instead of creating the "users" group, I just
> changed that to "dan," my group. It was after trying this and it not
> completely working that I read about "auth_admin" and learned that the
> admin policy rule was in /etc/polkit-1/rules.d/50-default.rules. I
> copied this to 40-admin.rules, because the file said not to edit it
> because it gets changed, which contains:
>> polkit.addAdminRule(function(action, subject) {
>> return ["unix-group:dan"];
>> });
> The original file contained "unix-group:wheel."
> I still couldn't get the drives to mount. I don't know if this last
> "admin" rule satisfied the "auth_admin" or not. So all until now is
> "Question 1."

It should have worked in the first place - presumably, there's still 
something wrong with your setup.

> "Question 2" involves a possible conflict in polkit policies. I don't
> know enough to be able to answer this one myself. But in digging around
> I found /usr/share/polkit-1/actions/org.freedesktop.usdisks.policy also.
> It contains a similar line to the one for udisks2, but with a possible
> glaring exception:
>> <action id="org.freedesktop.udisks.filesystem-mount">
>> <description>Mount a device</description>
>> <defaults>
>> <allow_any>no</allow_any>
>> <allow_inactive>no</allow_inactive>
>> <allow_active>yes</allow_active>
>> </defaults>
>> </action>
> I thing the "<allow_active>yes<allow_active" means that as long as I am
> logged into a tty, which I am, I should be able to mount filesystems
> without authentification. But the udisks2 policy used "auth_adm" which
> is obviously different. So, "Question 2" becomes, is this a conflict
> that requires resolution somehow?

I think auth-adm just means you have to be logged in as root; you want 
to be able to mount logged in as an ordinary user.

> And, lastly, Question 3. I use the Package Users Management System.
> Files get installed with the ownership and group of the name of the
> particular user. In my case, I use <package name>-<version>. In this
> case the polkit files are owned by user polkit-0.112 and are in a group
> by the same name. Until yesterday there was only one exception to what I
> do and that was 'xorg' which must be root:root and SUID. Yesterday I
> learned that polkitd must be "polkitd:polkitd" with the "sticky bit" set
> for the group. Other than these two applications, all the other ones
> that I have run fine as they are. The only thing I must do is be
> judicious in setting the sticky bit for those applications which need it.
> If my management system is causing this problem, I can fix it. First,
> however, I need to discover that this is the problem. Would someone who
> uses polkit check the ownership and permission of /usr/share/polkit-1/*
> and let me know what they are? It's possible that they must be
> "polkitd:polkitd," but before a run 'chown -R' I'd like to get some info.

The rules.d subdirectory needs to be owned by polkitd. In fact, this is 
what I've got:

chmod 4755 /usr/lib/polkit-1/polkit-agent-helper-1
chmod 4755 /usr/bin/pkexec
chown polkitd /etc/polkit-1/rules.d
chown polkitd /usr/share/polkit-1/rules.d

I'm not familiar with your style of package management - I just use a 
plain 'DESTDIR' method to install - but you don't seem to be picking up 
on some of these privileged commands, such as 'chown' - they should 
cause errors when you try installing as a non-priv user to the DESTDIR, 
so they have to be done 'post-install'.

I'm afraid I'm a bit short of time this evening, but this is a good link 
if you want to learn more about dbus and polkit:


You can use the tools it recommends to query polkit (and other dbus users)


More information about the blfs-support mailing list