On Sat, 5 Jun 2004 04:16, Valdis.Kletnieks@vt.edu wrote:
Also, anybody know where these come from? /lib(64)?/lvm-10(/.*) system_u:object_r:lvm_exec_t /lib(64)?/lvm-200(/.*) system_u:object_r:lvm_exec_t
These came from adjusting the Debian path names to the Red Hat naming convention. I'll fix them in my tree.
Please double-check - I've verified that this patch doesn't unintentionally relabel anything on my system, and does avoid mislabeling the two xemacs files, but there very well might be things that intend to use .* to greedily swallow across a / character for the types I changed.. if it's too drastic, probably 95% of the benefit could be gained by just changing all the .so.* to be .so(.[^/]*)* instead...
I've checked it and verified that it appears to do the correct thing according to the design. I believe it's good enough that everyone should use it.
There is one improvement that can be made however. Only class "file" should have type shlib_t or ld_so_t. The following six entries should have "--" added to specify that they only apply to the file class. This will improve the speed of setfiles, and may prevent some corner-cases from causing mis-labelled file system objects that can't be conveniently removed.
/usr/.*glibc.*-linux/lib(64)?/ld[^/]*.so(.[^/]*)* system_u:object_r:ld_so_t /usr/.*glibc.*-linux/lib(64)?/lib[^/]*.so(.[^/]*)* system_u:object_r:shlib_t /usr/.*redhat-linux/lib(64)?/ld[^/]*.so(.[^/]*)* system_u:object_r:ld_so_t /usr/.*redhat-linux/lib(64)?/lib[^/]*.so(.[^/]*)* system_u:object_r:shlib_t /usr/.*linux-libc.*/lib(64)?/ld[^/]*.so(.[^/]*)* system_u:object_r:ld_so_t /usr/.*linux-libc.*/lib(64)?/lib[^/]*.so(.[^/]*)* system_u:object_r:shlib_t