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 mat...@mattdm.org <http://mattdm.org/> _______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/polkit-devel
