beesnees at grm.net
Wed Dec 11 09:12:50 PST 2013
On 12/10/2013 02:34 PM, David Brodie wrote:
> On 10/12/13 17:59, Dan McGhee wrote:
>> 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.
Found it. What was wrong that is. Actually there were two things wrong
and one didn't actually involve polkit.
In trying to see exactly what files got installed where and with what
permissions, I wanted to re-build polkit and do a DESTDIR install. After
a number of frustrating configuration failures--I was trying to watch a
hockey game too--I discovered that /usr/lib/pkgconfig/mozjs-17.0.pc had
somehow become corrupted. I fixed it and polkit built just fine.
>> 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
This is what was wrong and it wasn't the Package Users system that
created the situation. It was my complacency in reviewing logs. At the
end of the screen output for 'make install" were four messages warning
that the ownership and permissions had to be what you presented above.
(Actually, the messages said that the agent helper and pkexec should be
owned by root.) In addition polkitd owning the rules.d directories, they
had to have mode 700. Actually the all did have that mode on my system,
but /etc/polkit-1/rules.d was owned by root.
I made these changes and now automounting works just fine.
> 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'.
This is, in essence, what happens in my system, but without DESTDIR. The
scripting *usually* filters out and logs the ownership and permissions
things. So I too must make these changes post-install. In this
particular instance since all the files installed without changing the
ownership and I didn't review my install log, I missed it.
> 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)
Yes, it looks like a valuable article. I was debating on whether or not
to install Qt, but now I will in case I have any other situations with
dbus and polkit.
David, thank you so much for your help. I really appreciate it. Not only
is my system working the way I want it too, I also learned something.
More information about the blfs-support