[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC] /var versus /srv



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 27 Sep 2007 08:55:17 -0400
Steve Grubb <sgrubb 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 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG+/U1+YBsl9wN1AkRAr6UAJ9RzShmujbmAUjF21LcQM2uOvKF3ACfVoiE
x7MtGJb4LrsTBuDSE/KC7QA=
=3ySW
-----END PGP SIGNATURE-----


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]