Anthony Towns <aj@azure.humbug.org.au> writes: > On Sun, Nov 10, 2002 at 11:26:31AM -0800, Thomas Bushnell, BSG wrote: > > > /usr/share is not appropriate for that, as it is the OS's playground > > > (and I can't see any use for the OS installing secrets there). > > > For site-specific secrets /usr/local/share is a better choice. > > "root users" is not somehow not the OS. For example, root users store > > secrets in the shadow password files. > > I'm speaking of secrets that *OS* programs need to have, and which > > should be shared among cooperating machines. > > That doesn't particularly make sense. If the "secret" is distributed > as part of Debian, it's not a secret -- anyone can buy their own copy > of Debian, pull apart the debs and find out what it is themselves quite > happily. So the secret has to vary between machines, which either makes > it configuration info that's site specific, in which case it should go > into /etc, or variable data maintained entirely by a program, in which > case it should go into /var, or completely site-specific in which case > it should go somewhere site-specific, like /home, /srv, /usr/local, etc. > The contents of /etc and /var are allowed to be shared amongst machines, > it's simply expected that which files get shared and how is more > complicated than for /usr, since they're much more site-specific.
Geez. I *wrote* the specification for the share directory that went into FHS. The point is that it is data which is *shared*, and that says nothing about whether it is public or not. /etc is not guaranteed to be sharable, /usr/share *is*. One such thing that can be shared, but which should also be secret, is a nethack bones level file. That shouldn't go in /var, because it *should* be shared normally by a group of cooperating machines. (The whole point of nethack bones files is that they cross over between different players.)
