patch -- config files in /etc

[David Zeuthen]

On Mon, 2009-11-30 at 12:40 -0500, Matthew Miller wrote:
> 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.

There's a bunch of prior art where application store data like this
in /var and not /etc. Many people use "application data" and
"configuration" interchangeably (even myself) - iscsi-initiator-utils is
one example. Don't let the FHS fool you that these are totally separate
things.

> > 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?

Not really - they are different things - you could have a small setup
where admin means unix-user:dilbert and unix-user:davidz. Or where it
means unix-group:staff.

>  (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.) 

I think it's fine to do this - I expect that some day we'll have UI to
edit the "what admin means" setting just like it is useful to change it
by creating a config file in /etc/polkit-1/localauthority.conf.d.

> > 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.

What happened in F12 was not a polkit issue, it was a PackageKit issue.
And the defaults did get changed within 48 hours because of the
over-whelming push-back. So it was a bug in PackageKit. And it got
fixed.

(If there's anything positive about that incident it's that maybe it
opened peoples eyes to the problem that Fedora maybe shouldn't be a
"general purpose OS" - we really need different policies (such as
different .pkla-files) in e.g. desktop and server spins - e.g. we want
the stock F12 behavior but only in a desktop-spin, never in a
server-spin)

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

The only possible solution that I could be made to agree with involves
reading files .pkla files from both

 /var/lib/polkit-1/localauthority
 /etc/polkit-1/localauthority

though this really sucks. But there is a ton of prior art where this is
done (hal, udev, etc.) so I guess we could do this.

So if you want to do this, file a bug with a patch and we'll take it
from there. Btw, it would be nice also to use inotify to watch
directories in polkit-1/localauthority instead of hardcoding this

               |-- 10-vendor.d
               |-- 20-org.d
               |-- 30-site.d
               |-- 50-local.d
               ‘-- 90-mandatory.d

Thanks,
David