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: http://www.linuxjournal.com/article/10455 You can use the tools it recommends to query polkit (and other dbus users) Regards, David -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
