[RFC] /var versus /srv

Lamont Peterson lamont at gurulabs.com
Thu Sep 27 18:23:49 UTC 2007

Hash: SHA1

On Thu, 27 Sep 2007 08:55:17 -0400
Steve Grubb <sgrubb at redhat.com> wrote:

> On Thursday 27 September 2007 07:03:08 Andy Green wrote:
> > But when you create a file, by cp or whatever, it must use private
> > knowledge about the specific path's "natural" context or it can't
> > automagically label new files correctly based on where they were
> > created.
> Correct. Cp has been coded to look at the originating context and
> apply that to the destination context when the --preserve option is
> supplied. It does not change the policy and the first time a relabel
> occurs, the context may be reset.
> > Maybe it will be possible to adjust the policies to accept both
> > /var/blah and /srv/blah, or via a bool.
> It looks like a couple daemons were done like this. However, its not
> all daemons and you have to move the files exactly where selinux
> policy says or you are fighting selinux.

No, the "policy" doesn't say anything about file locations.  The .fc files have something to say about file locations and are what is used for relabeling and thus need to have an entry added/edited if /srv/www/ and such were made to be default locations.

The point is, SELinux policies should just work and .fc would need an extremely minor update in order to support additional paths like /srv/www/ for confined services.  Additionally, there's no reason that both /var/www/ and /srv/www/ couldn't be listed for Apache in the .fc files.  Thus, using "SELinux would have be changed" as an argument against using /srv/ as a default path for things that it makes sense to have in there is nonsense.
- -- 
Lamont Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]

NOTE:  All messages from this email address should be digitally signed with my
       0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
       well as other keyservers that sync with MIT's.
Version: GnuPG v1.4.7 (GNU/Linux)


More information about the fedora-devel-list mailing list