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?
*_disable_trans was removed because it caused as many problems as it
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.
That it wouldn't survive a relabel makes it pretty worthless.
I was thinking about permissive domains when I was writing the
original e-mail. Good to hear it is being worked on.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
