It may be useful to run a setup.py to add a policy, as normally on a system, python packages are installed in/usr/local.

> on the other hand, if policykit recognizes /usr/local/share/polkit-1, the smart administrator can place their yumex.rules within /usr/local/share/polkit-1/rules.d and not have to worry about it being overwritten.

That’s not how the *.rules file loading works; all of the files are loaded, in a lexical order, even if they have the same base name.

Instead, you can name the override e.g. 00-yumex.rules, and the code run in there will be run before whatever the yumex package installs in yumex.rules.

As for /usr/local being specific to a particular host, why not just use /etc?

> As for /usr/local being specific to a particular host, why not just use /etc?
I assume you're making reference to /etc/polkit-1/rules.d ... but what about the absent /etc/polkit-1/actions? adding that directory and placing a .policy file in there has no effect. also, is it documented somewhere that packages cannot / should not place policykit .rules or .policy files in /etc?

> Instead, you can name the override e.g. 00-yumex.rules, and the code run in there will be run before whatever the yumex package installs in yumex.rules.
is it documented somewhere that packages cannot / should not name policykit .rules or .policy files starting with "00-"?

keep in mind i wasn't referring to configuration being merely overridden, but overWRITTEN (as in the custom configuration files' contents lost).

(In reply to beommasha from comment #3)
> > As for /usr/local being specific to a particular host, why not just use /etc?
> I assume you're making reference to /etc/polkit-1/rules.d ... but what about
> the absent /etc/polkit-1/actions? adding that directory and placing a
> .policy file in there has no effect.

That runs into exactly the same issue; actions/* are _not_ designed to be overridable by simply using the same file name.  Override-by-file-name is a systemd-ism not at all common in the ecosystem.

Besides, actions/* are application-installed static files not anticipated to be overridden and not designed to be overridable.  Whatever the administrator is expected to want to change should be doable using *.rules files.  (Or, if we are talking about changing/adding translations and core properties, that’s really changing the application, not its configuration, and it seems entirely appropriate to ask the administrator to package the changed application as an updated RPM.)


> also, is it documented somewhere that
> packages cannot / should not place policykit .rules or .policy files in /etc?
> 
> > Instead, you can name the override e.g. 00-yumex.rules, and the code run in there will be run before whatever the yumex package installs in yumex.rules.
> is it documented somewhere that packages cannot / should not name policykit
> .rules or .policy files starting with "00-"?

Neither of these need to be documented; the system administrator, who is overriding the default .rules of a specific application, by definition knows what the original name of the application-installed .rules file is, and can therefore choose a file name which sorts before it.

It’s not interesting to speculate about what would happen if a future version of that package were updated to intentionally override the administrators’ configuration by choosing a different file name which sorts even earlier; the package is already running code as root, it can do whatever it wants without doing it in this difficult and limiting way.


> keep in mind i wasn't referring to configuration being merely overridden,
> but overWRITTEN (as in the custom configuration files' contents lost).

That’s really up to the distributions packaging system.  At least RPM would just overwrite a non-%conf file (such as /usr/share/*/*.rules, yes) without warning, IMHO reasonably. Files marked as configuration are treated differently, usually with more care.

The admin can always embed the company’s name to make the file name unique. But between using /etc instead of /usr/share, and testing the changes, that is only a layer of insurance for extra confidence, not inherently necessary.

To step back a bit: It seems valuable to have all of the configuration consolidated in a single place, so that it is easy to understand it in its entirety.  The /etc vs. /usr/share split is already more complex than this, to supposedly make shipping “stateless” systems much easier (not sure about that, honestly), and to cleanly separate distribution-shipped and administrator-created configuration (clearly true).

Adding /usr/local/share would make the configuration even more dispersed, making it easier for an administrator to overlook a configuration file (or, potentially, for an attacker to hide an unexpected override).  And if it is not clear how /etc would differ from /usr/local/share, why have both?

> That runs into exactly the same issue; actions/* are _not_ designed to be
> overridable by simply using the same file name.

I have not used the word override. The issue I'm describing is that the administrator's .policy files if placed into a package-writable place can be overwritten due to any naming conflicts that might eventually crop up. Not only would the intended functionality stop working at that point, but the administrator's work would also be lost. An example in which I use .policy files is to enable pkexec to work with certain applications. The following command, for example, will not work unless a custom .policy file is added:
pkexec caja /;

If the administrator names the file pkexec.policy or caja.policy, or really anything else, there's potential that the file could get overwritten by a package update or installation. That's the issue I have been describing.

> Whatever the administrator is expected to want to change should be
> doable using *.rules files

Can you tell me a way to make the command listed above work with a .rules file?

> Neither of these need to be documented; the system administrator, who is
> overriding the default .rules of a specific application, by definition knows
> what the original name of the application-installed .rules file is, and can
> therefore choose a file name which sorts before it.

That's not the use case I've been describing. Please re-read original comment:
> for example, as things stand currently with policykit, the administrator has
> to put e.g. yumex.rules in /usr/share/polkit-1/rules.d -- but if an update to
> the yumex application starts including it's own yumex.rules, it will overwrite
> the administrator's configurations

Therefore, the administrator doesn't strictly know what the file will be named. Maybe if/when yumex started including rules they'd name it 00-yumex.rules because they simply saw a .rules file labeled that way in an online example. The administrator has no guarantee their file won't be overwritten when an application is updated or installed.

> It’s not interesting to speculate about what would happen if a future version
> of that package were updated to intentionally override the administrators’
> configuration by choosing a different file name which sorts even earlier; the
> package is already running code as root, it can do whatever it wants without
> doing it in this difficult and limiting way.

mmmm ... snarky :-)
um, again, and I can't seem to stress this enough ... these scenarios you're noting are your own inventions and have nothing to do with the use case I've been conveying.

> That’s really up to the distributions packaging system.  At least RPM would
> just overwrite a non-%conf file (such as /usr/share/*/*.rules, yes) without
> warning, IMHO reasonably.

so it's your (apparently very strongly held) opinion that administrators should not be able to make customizations by making use of polkit .rules and .policy files?

> It seems valuable to have all of the configuration consolidated in a single
> place ... Adding /usr/local/share would make the configuration even more
> dispersed, making it easier for an administrator to overlook a configuration
> file

the administrator who (properly) uses /usr/local/share for their custom stuff over /usr/share is not going to forget the difference

> (or, potentially, for an attacker to hide an unexpected override).

straw grasping, much?

> And if it is not clear how /etc would differ from /usr/local/share,
> why have both?

files placed in /usr/local (not just /usr/local/share) are protected by that distinction from being overwritten by package updates and installations. that's the difference.

(In reply to beommasha from comment #6)
> If the administrator names the file pkexec.policy or caja.policy, or really
> anything else, there's potential that the file could get overwritten by a
> package update or installation. That's the issue I have been describing.

OK…

> > It’s not interesting to speculate about what would happen if a future version
> > of that package were updated to intentionally override the administrators’
> > configuration by choosing a different file name which sorts even earlier; the
> > package is already running code as root, it can do whatever it wants without
> > doing it in this difficult and limiting way.
> 
> mmmm ... snarky :-)

That’s not snarky; that is _fundamental_. In the Linux security model, administrators can’t be fighting with (non-sandboxed) applications they install; they are always going to lose.

If the administrator names a file mycompany-caja.policy, an _ordinary_ application not out to attack the administrator is not going to conflict with that name.  If the application is trying to attack the administrator and introduces a file named mycompany-caja.policy, then introducing /usr/share/local is not going to help at all because the application can just as well introduce an /usr/share/local/polkit-1/mycompany-caja.policy.

> > That’s really up to the distributions packaging system.  At least RPM would
> > just overwrite a non-%conf file (such as /usr/share/*/*.rules, yes) without
> > warning, IMHO reasonably.
> 
> so it's your (apparently very strongly held) opinion that administrators
> should not be able to make customizations by making use of polkit .rules and
> .policy files?

There’s the /etc space for .rules. You’re right that there isn’t a great place for introducing extra pkexec permissions for .policy, but there is a good enough place.


> > It seems valuable to have all of the configuration consolidated in a single
> > place ... Adding /usr/local/share would make the configuration even more
> > dispersed, making it easier for an administrator to overlook a configuration
> > file
> 
> the administrator who (properly) uses /usr/local/share for their custom
> stuff over /usr/share is not going to forget the difference

Maybe; but only very few are regularly updating custom stuff in there, many more are going to be surprised the first time they see a config file in there.


> > And if it is not clear how /etc would differ from /usr/local/share,
> > why have both?
> 
> files placed in /usr/local (not just /usr/local/share) are protected by that
> distinction from being overwritten by package updates and installations.
> that's the difference.

I don’t know about all possible package update systems, but this is certainly not the case for RPM at all, and it’s not _really_ the case for any packaging system which allows packages to contain arbitrary scripts run as root. (And if you think that nobody would place files into /usr/* in a post-install script, this does happen, usually when a multi-platform vendor finds it necessary to make a package, any package that works well enough.)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/polkit/polkit/issues/51.