-----BEGIN PGP SIGNED MESSAGE-----
Nathan Grennan wrote:
Daniel J Walsh wrote:
> chcon is just like chown or chmod, and actually change a file context to
> httpd_sys_content_t will survive a relabel, which you really should not
> need to do. If you cp the contents of the directory they should adopt
> the context of the destination directory. Also you could use restorecond
> to watch for the creation of files in the directory.
Would other contexts survive though? httpd_sys_content_t is really here
nor there in that situation, because it is the default policy.
So I could custom configure restorecond, but why does it even have to be
a daemon. Why couldn't the kernel just to it automatically during the move?
Well the kernel knows nothing about file paths. The real problem is the
semantics of the mv command. The mv command maintains the file context
of the source. So if you mv from user_home_t into httpd_sys_content_t
it will stay user_home_t. cp on the other hand adopts the context of
the destination by default. This mirrors the way DAC permissions work.
The problem is people understand and have experienced DAC permissions.
So when apache can't read a file you check the ownership and the
permissions, but with MAC/SELinux you also need to check the file context.
> *_disable_trans was removed because it caused as many problems as
> solved. When you disable trans on one domain, you can cause other
> domains to to blow up because file context gets screwed up.
This makes sense.
> If you really want to disable trans you could change the context of
> httpd to bin_t. chcon -t bin_t /usr/sbin/httpd, but this will not
> survive a relabel. We are hoping to add permissive domains pretty soon,
> where you define httpd as a permissive domain, and it would only report
> access problems and not enforce them.
httpd_* context does survive relabels but it is always better to use
semanage fcontext -a ...
To manipulate the systems default labeling.
That it wouldn't survive a relabel makes it pretty worthless.
Well you really should not be relabeling regularly (You should Never
need to). Although an update to policy could relabel the /usr/bin/httpd
file on you.
I was thinking about permissive domains when I was writing the
e-mail. Good to hear it is being worked on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----