On 10/17/2009 09:41 AM, Matthias Clasen wrote:

On Sat, 2009-10-17 at 09:24 +0530, Rahul Sundaram wrote:

...

Hi,

This GUI tool seems to have been lost in the transition to PolicKit-1. Is there a plan on getting it back? It was quite convenient. If not, what is the recommended method?

We don't plan to bring a ui like that back. If you need to tweak policy, the local authority uses a simple file-based configuration, see pklocalauthority(8). Medium-term, we want to have a simple group-based configuration that will be accessible via some ui, see the polkit-desktop-policy package for the groundwork.

To help me understand this better, can you give me a example? Let's say I want to tweak PackageKit's policy to not ask for root password even when untrusted packages are being installed, how do I go about doing that?

Rahul

Am Samstag, den 17.10.2009, 16:34 -0400 schrieb David Zeuthen:

On Sat, 2009-10-17 at 09:49 +0530, Rahul Sundaram wrote:

...

To help me understand this better, can you give me a example? Let's say I want to tweak PackageKit's policy to not ask for root password even when untrusted packages are being installed,

(this is not a good idea but let's ignore that for the time being)

...

how do I go about doing that?

Did you look at the EXAMPLES section in the man page Matthias mentioned? If it's not clear how to do it after reading that man page, do ask here and ideally include a patch to the source for the man page. Thanks.

You want a person who not fully understands the concept to come up with a patch?

Although I was able to configure Rahul's example, I still don't understand the manpage. Let me give you some examples:

Configuration for the Local Authority are read from files in the /etc/polkit-1/localauthority.conf.d directory. The file 50-localauthority.conf contains the settings provided by the OS vendor. [snipped] The Local Authority reads files with .pkla from the following directories ....

So what is the relationship between the .conf files in /etc/polkit-1/localauthority.conf.d and the .pkla files in /var/lib/polkit-1/? Do they coexist, does one overwrite the other or are they generated from the conf files? If so, by what program?

Allowed values are similar to what can be used in the defaults section of .policy files used to define actions

This is the first time .policy files are mentioned. Where are they and what is their purpose?

EXAMPLES The following .pkla file

We just learned that .pkla files live in /var/lib. So people are supposed to edit files in /var/lib that get overwritten on the next update?

 David

Regards, Christoph

Am Samstag, den 17.10.2009, 21:40 -0400 schrieb Matthias Clasen:

On Sun, 2009-10-18 at 03:14 +0200, Christoph Wickert wrote:

A couple of good questions, even if presented in a somewhat passive-aggressive tone.

Sorry about that, it wasn't meant to be aggressive in any way. Nevertheless I have to admit that I found David's "come up with a patch" attitude somewhat arrogant. I sure the manpage will not get better if people who don't understand the concept completely start adding "corrections".

...

So what is the relationship between the .conf files in /etc/polkit-1/localauthority.conf.d and the .pkla files in /var/lib/polkit-1/? Do they coexist, does one overwrite the other or are they generated from the conf files? If so, by what program?

The man page could certainly be clearer on this point. My understanding is that files in /etc/polkit-1/localauthority.conf.d _can_ overwrite each other (according to their ordering), but there is no overwriting between configuration in /etc/polkit-1 and /var/lib/polkit-1.

The first is clear, the latter IMHO not.

The files in /etc/polkit-1/localauthority.conf.d can only configure a single aspect: which identities count as 'administrator'. This is done with the key 'AdminIdentities'.

Thanks for the clarification, I think this should be in the manapge somehow.

The .pkla files in the various /var/lib/polkit-1/localauthority/ subdirectories can override each other (according to the ordering of the directories). The contain authorization entries that modify the policy for individual actions. As shown in the example in the man page.

Yes, this is understandable from the current manpage.

...

This is the first time .policy files are mentioned. Where are they and what is their purpose?

.policy files live in /usr/share/polkit-1/actions. They are installed by mechanisms that are using PolicyKit, to define the actions that they want to be controlled by PolicyKit. See the section 'Declaring Actions' in polkit(8).

Maybe a reference to polkit(8) should be added here and not only at the bottom.

...

We just learned that .pkla files live in /var/lib. So people are supposed to edit files in /var/lib that get overwritten on the next update?

If you study the contents of the polkit package, you will find that all the subdirectories below /var/lib/polkit-1/localauthority are empty. If you create files there, they will not be overwritten by updates.

I think the man page understandable by itself without looking at the filesystem or rpm database.

The /var/lib/polkit-1/localauthority/10-vendor.d directory is meant for default policies provided by the vendor, and the polkit-desktop-policy package installs its .pkla files there. Those will of course be overwritten by updates. But they are not meant for editing, anyway. If you need to tweak the policy, create your own .pkla file and put it e.g. in /var/lib/polkit-1/localauthority/30-site.d.

Understood, but this is not really following the fhs. .pkla files are config files, so shouldn't they be in /etc?

Regards, Christoph

Am Sonntag, den 18.10.2009, 14:07 -0400 schrieb Matthias Clasen:

On Sun, 2009-10-18 at 12:31 +0200, Christoph Wickert wrote:

...

Understood, but this is not really following the fhs. .pkla files are config files, so shouldn't they be in /etc?

'config file' is really a bit simplistic, and doesn't really describe the situation adequately. Whether something is a config file or not depends a lot on your role. As I mentioned earlier, we have a package that installs files in /var/lib/polkit-1/localauthority/10-vendor.d, those are certainly not config files in the sense that you as a local administrator are supposed to edit them.

Agreed, but I as the administrator would need to configure things in /var/lib/polkit-1 in order to customize the settings. This is usually done in /etc and called "configuration".

And 20-org.d, 30-site.d don't really fit into the 'host-specific configuration data' bucket either.

Not really sure about 20-org.d and 30-site.d because after reading the manpage I still don't fully understand the meanings of "the organization deploying the system" (GNOME, KDE, Xfce? My company?) and "site deploying the system" (what does "site" mean in this context?).

Anyway, I think we both agree that 50-local.d definitely contains "host-specific configuration data", do we?

Regards, Christoph

On Sun, 2009-10-18 at 22:30 +0200, Christoph Wickert wrote:

Just a quick follow-up:

Am Sonntag, den 18.10.2009, 22:17 +0200 schrieb Christoph Wickert:

...

Anyway, I think we both agree that 50-local.d definitely contains "host-specific configuration data", do we?

Quoting http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION

"var/lib : Variable state information Purpose This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation."

Right. Users don't.

Site or org administrators can install suitable policies there, preferably in the form of a policy package.

On 10/18/2009 11:12 PM, Matthias Clasen wrote:

On Sun, 2009-10-18 at 22:30 +0200, Christoph Wickert wrote:

...

Just a quick follow-up:

Am Sonntag, den 18.10.2009, 22:17 +0200 schrieb Christoph Wickert:

...

Anyway, I think we both agree that 50-local.d definitely contains "host-specific configuration data", do we?

Quoting http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION

"var/lib : Variable state information Purpose This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation."

Right. Users don't.

What the FHS also says is it is application state data, a.k.a. transactional data, and not configuration data. Since the polkit-1 files should never be changed by users, and should thus also not be changed by a UI application, I fail to see how these configuration files can be in /var/lib/ instead of /etc/.

More importantly, the definition of what is vendor, org, site and local is, IMHO, as follows:

vendor is what PolicyKit ships as a default policy, much like perl and ruby have vendor libraries (modules, extensions). This policy can be overriden or extended by an organisation (example.org Ltd.) in org (possibly through configuration management). Site is for what packages deploy, much like perl and ruby use site directories, and local then finally gives an organisation the opportunity to lay down a policy applicable to just some hosts, only to finally have the mandatory policy (package A / local.d can set foo to be allowed but organisation does not want to allow it), much like perl and ruby use or are going to use /usr/local/lib{,64}/ and /usr/local/share/.

It would make more sense to me to just have vendor (PolicyKit), site (packages), org (my configs) and local (my host specific configs) -in that order. It doesn't make much sense to me to have site be parsed after org, only to then have the same thing in mandatory again.

Does such make sense compared to how it is supposed to be used, and if put in more proper wording, would such be how it could be explained in the man page?

Site or org administrators can install suitable policies there, preferably in the form of a policy package.

Org, site and local administrators probably deploy some kind of configuration somehow (I'll withhold from my recommendations). It wouldn't matter much in what directory they are exactly (type once, deploy many, many times). It does matter in what order various files are to be parsed, and what files from which sources might end up in various places exactly. Could we have some more clarification on what the various directories in /var/lib/polkit-1/localauthority/ are supposed to be used for, and what could (may or may not) put files in these directories?

-- Jeroen

On 10/17/2009 10:34 PM, David Zeuthen wrote:

On Sat, 2009-10-17 at 09:49 +0530, Rahul Sundaram wrote:

...

To help me understand this better, can you give me a example? Let's say I want to tweak PackageKit's policy to not ask for root password even when untrusted packages are being installed,

(this is not a good idea but let's ignore that for the time being)

Actually you're not in a position to determine whether this is or is not a good idea.

-- Jeroen

On 10/20/2009 04:06 PM, David Zeuthen wrote:

On Sun, 2009-10-18 at 13:21 +0200, Jeroen van Meeuwen wrote:

...

On 10/17/2009 10:34 PM, David Zeuthen wrote:

...

On Sat, 2009-10-17 at 09:49 +0530, Rahul Sundaram wrote:

...

To help me understand this better, can you give me a example? Let's say I want to tweak PackageKit's policy to not ask for root password even when untrusted packages are being installed,

(this is not a good idea but let's ignore that for the time being)

Actually you're not in a position to determine whether this is or is not a good idea.

Actually I'm uniquely qualified to make statements like that since I wrote the mechanism (e.g. PolicyKit) allowing people to aim for their foot and blow their whole leg off.

(Allowing people to hang themselves (or shoot their leg or foot off or whatever) is of course not the goal of PolicyKit... but since PolicyKit is a security-mechanism it does allow people to do such things even if they are crazy.)

Mind you, not only am I qualified to make such statements, it's my goddamn responsibility, as the author of the software, to tell people "don't do that, it's a root-exploit in the making" - especially if it's on a public mailing list where authors of "helpful" guides a'la "How to make Fedora Work" recipes etc. will find the discussion via Google and other search engines.

Good god... So this is how you think you can determine whether allowing users to install unsigned packages is a good idea or not, better then anyone else can? I'm doubting whether you've ever administered some real-life desktop systems

FWIW, I love PolicyKit for giving me more granular control (potentially) over what users can do; I wouldn't want them to remove my configuration management packages for example, but sudo yum privileges often extend too much beyond the boundaries of what is acceptable delegation. That is, in most of the situations where I manage desktop systems.

-- Jeroen

On 10/20/2009 08:40 PM, Naheem Zaffar wrote:

2009/10/20 Jeroen van Meeuwen <kanarip@kanarip.com mailto:kanarip@kanarip.com>

I wouldn't want them to remove my configuration management packages
for example, but sudo yum privileges often extend too much beyond
the boundaries of what is acceptable delegation. That is, in most of
the situations where I manage desktop systems.

I think even this can be lived with as long as it does not turn into a Vista-esque UAC fest. There needs to be a way to remember trust given withpout having to resort to manually adding/editing config files - they may be useful/the best solution in an enterprise/other controlled environment, but that is not the case on a home desktop system.

Sure enough it can be lived with, I haven't been doing anything else for a long time. Yet though, there is this magic gray boundary between what users can do on their own and what they need me and my colleagues for. Previously, making sure I wasn't bothered for foo I wanted the users to be able to do themselves, but staying on the safe side of giving them privileges caused me to need to step in, was a huge pain in the ass. Like I said, I love the more granular control a mechanism like PackageKit allows us to configure.

A simple tick box "remember this action" like there was before would IMO fix many of these annoyances without giving the full GUI for each authorisation that existed before.

I don't install desktop systems, nor do I ever sit behind a keyboard of one that I manage. We do it all remotely, and centralized. A "remember this action" when the user is asked for the root password (which not a single person knows) doesn't help. Hence we need to deploy policies if we wanted to use PolicyKit, and until we've figured out the exact semantics we're still using the old systems. We want to say "deny" or "allow", or "authenticate as a wheel(system)/sysadmin-local(ldap)/sysadmin-main(ldap) member" and then allow.

-- Jeroen

On 10/20/2009 09:35 PM, Bill Nottingham wrote:

Jeroen van Meeuwen (kanarip@kanarip.com) said:

...

Good god... So this is how you think you can determine whether allowing users to install unsigned packages is a good idea or not, better then anyone else can? I'm doubting whether you've ever administered some real-life desktop systems

Given that it essentially allows any user to root the box, yeah, I think it's a safe statement that it's a bad idea to grant that to users and not grant them other privleges.

Yes it does potentially allow users to nuke their systems if they know how to, or install packages from people that know how to. Essentially, those packages come from proprietary vendors that don't know how to just because they are proprietary vendors, but if they were to know how to, then installing their packages would nuke a system or two.

You're entirely right, both you and David. It is a very bad idea to have your users install an RPM that is unsigned (which is not the same as an untrusted source), and so we should all flip the bird to the customer (also part of the ecosystem that enables Red Hat to pay your salary).

Last I'll say in this "discussion", FFS.

-- Jeroen

On Sun, 2009-10-18 at 13:55 +0200, Jeroen van Meeuwen wrote:

I would put it in /var/lib/polkit-1/localauthority/20-org.d/10-packagekit-policy.conf.

That should be /var/lib/polkit-1/localauthority/20-org.d/10-packagekit-policy.pkla, I think.

What is "any subject"? Both Active and Inactive? Then why not require both to be set and eliminate this variable? Is anything other then Active and Inactive included in Any?

If you read the small print, ResultActive/Inactive are described as applying to subjects in _local_ sessions. Presumably, ResultAny covers subjects in remote sessions (or even without sessions ?) as well.

What does Require* have to do with Result* exactly?

This is a bug, I would say. The paragraph is supposed to refer to ResultFoo, not RequireFoo. I've reported it here for you: https://bugs.freedesktop.org/show_bug.cgi?id=24640

[1] $ polkit-config-file-validate ~/tmp/10-packagekit-policy.conf polkit-config-file-validate: error while loading shared libraries:

You really should not have polkit-config-file-validate installed. It is part of the PolicyKit 0.9 packages that have been obsoleted by polkit.

Matthias