patch -- config files in /etc

[Matthew Miller]

On Mon, Nov 30, 2009 at 11:45:52AM -0500, David Zeuthen wrote:
> The short answer:
> "One mans application data is another mans configuration data"
> Or put in another: Files in /var/lib/polkit-1/localauthority are just
> not configuration files.

Not to play "gotcha", but the pklocalauthority man page calls them
configuration files. And they pretty clearly act like config files: they're
used to configure the Local Authority.

> First the files in /etc/polkit-1/localauthority.conf.d - these files are
> used to configure whether you want admin authentication to mean "use the
> root password" or "consider user1,user2,user3 admin" or "consider users
> in UNIX group group1 admin". This is something that users are likely to

This a tangent to the main issue, but I'm a little bit concerned about that
architecturally. Isn't that basically duplicating what can be done in the
.pkla files except with a very broad brush? For example, I have a
configuration for org.libvirt.unix.manage which allows members of a group to
auth_self instead of auth_admin; isn't that better than broadly changing
what admin means? (Again, tangent to the main issue; I don't have a
particularly strong opinion on this. And I don't think it's a problem to be
able to define what "admin" means; just not sure if that's the best way to
describe policy.) 


> want to change and that's why it's in /etc. To avoid the atrocity that
> is config file handling, a directory is used.

I have to disagree with the idea that Local Authority configuration isn't
something users might want to change. As we saw recently with the F12
PackageKit configuration, this is *absolutely* something people might want
to alter as appropriate for their site.

I can see the argument for putting package-manged configurations outside of
/etc -- generally, /usr/share is used for that purpose. (Although there's
plenty of precedent for leaving it in /etc as well.)

But 50-local.d is clearly defined in your documentation as for local usage,
and therefore I don't think there's any question of any other logical place
for it but /etc. 

> Second, the files in /var/lib/polkit-1/localauthority - these files are
> really application data that specify how the Local Authority should
> work. As configuring this stuff requires insight into what each action
> means (and is security sensitive) it is in /var exactly because users
> shouldn't be messing around with it. The intention is that vendors and

There's plenty of security-sensitive files in /etc, which a non-informed
admin can break. Knowledgeable admins, however, should be allowed to make
their own decisions. "Data that specifies how the authority to work" is
*definitely* configuration data; the argument that it's _very special_
configuration data means that it's all the more important to have it in the
standard place, not less.

> sites can supply packages (e.g. RPMs) with these files. And that's why
> it's in /var, not in /etc. See e.g. polkit-desktop-policy.

That's definitely a good idea and there's certainly room for it. However,
there's no reason we shouldn't support other standard mechanisms for
managing config files, like cfengine and puppet. In fact, the whole system
you've got set up with org.d and site.d seems ideally suited for that kind
of thing -- for example, vendor and organization policy could by by rpm
policy packages, with site policy managed by a puppet installation, and
machine-specific overrides in local.d.


> Also, the Local Authority is really just one implementation of a polkit
> Authority. Other authority implementations are free to read data from
> any source (including e.g. LDAP servers) on how to work. As such,
> putting the Local Authority files in /etc (which is typically used for
> configuration) is a bad idea as they may not even be used.

I don't think this a large concern -- if you configure nsswitch.conf to use
LDAP instead of /etc/passwd, the password file is still there. And there's
many other examples. Same with sudo and LDAP vs. /etc/sudoers, for that
matter.


> Sorry, but this is not going to change.

I hope you can reconsider, because while the actual change is trivial, it's
really the right thing to do.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>