Colin Walters wrote:
After thinking about it, I think preserving file context would be the problem. So a different solution, mightOn Thu, 2005-01-20 at 19:56 +1100, Nick Urbanik wrote:
This raises a can of worms when maintaining the program, and the
question arises as to which is the "real one".
Well...no, since you still have the same source code and build process, etc. This solution is a lot like what pre-SELinux chroot scripts did for bind, etc.
I'm likely to forget
to update one or the other.
I'd imagine that your Makefile or whatever would install the two copies explicitly. Or you could do it in the RPM build process.
"Which one do I enter into version
control?" is a question I would ask myself often.
You enter binaries into version control?
Where are SELinux attributes stored? In the inode?
They are tightly coupled to the inode, yes. Just like Unix permissions are.
If not, can hard
links be given different attributes?
No; hard links are just additional names for the same object. SELinux protects the actual object, not names or references to objects.
The other solution is to define a new type, and grant both domains inWell, that may be more managable in the long term. Can you suggest a
question access to it. This is a lot more complex; now you have to
consider potential information flow between the two domains which were
(presumably) separate before.
(relatively) simple way of doing that?
You'd have to explain more about your setup. Are you just trying to run the CGI script as an ordinary user from unconfined_t?
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
be to take advantage of the http_tty_comm boolean and turn on access to it from httpd_$$$_script_t so if an
admin or an unconfined_t process ran the script it would be able to output to the terminal.
Dan
