On Mon, 2013-05-27 at 19:01 -0400, Roland Roberts wrote: SELinux contexts for /home are treated a bit differently than other locations. Try instead: (from: man semanage): > For home directories under top level directory, for example /disk6/home, > execute the following commands. > # semanage fcontext -a -t home_root_t "/disk6" > # semanage fcontext -a -e /home /disk6/home > # restorecon -R -v /disk6 > I'm trying to clean up selinux contexts and having trouble. The system > is a new install of Fedora 18, but the home directories have been > preserved for a long time. Because the system runs boot on raid-1, it > was installed as Fedora 17 and then I used fedup to move to Fedora 18. > > My home directories are automounted via NFS and an NIS map. I mount them > on the clients with an explicit context: > > 270 roland> ypcat auto.home > -rw,soft,intr,tcp,context="system_u:object_r:user_home_t:s0" > archos.rlent.pnet:/data/home/& > > However, my troubles right now are confined to the server. > > The real home directory is /data/home so /data/home/roland is mounted on > /home/roland. All clients see the same mount point, even the server > remounts this way. > > Most of the selinux context information is wrong, probably because some > of these files have been hanging around roughly since RedHat 3.0.3. Yes, > really. Although the content has surely changed (e.g., .bashrc). > > To get started, I've done this > > semanage fcontext -a -t home_root_t /data/home > semanage fcontext -a -t user_home_dir_t '/data/home/(.*)' > semanage fcontext -a -t lost_found_t /data/home/lost+found > restorecon -v -R /data/home > > That gave the surprising result of doing absolutely nothing. So I > brute-forced it and did > > semanage fcontext -a -t home_root_t /data/home > semanage fcontext -a -t lost_found_t /data/home/lost+found > for D in $LIST; do semanage fcontext -a -t user_home_dir_t > /data/home/$D; done > restorecon -v -R /data/home > > The above did not work for the lost+found directory. I haven't figured > out why. I tried deleting all the contexts I had set and starting over > and I tried setting the context just on lost+found repeatedly to no > avail. lost+found remains default_t. > > Next, I log in via ssh to my user account. Since I have X forwarding > turned on, this results in an .Xauthority file being created. If I run > (as root, from another window) restorecon, I get this > > [root@archos ~]# cd /data/home/roland > [root@archos roland]# restorecon -v -R /data/home/roland > restorecon reset /data/home/roland/.Xauthority context > unconfined_u:object_r:xauth_home_t:s0->unconfined_u:object_r:default_t:s0 > > So the file was created with the correct context, but it gets zapped > with restorecon. I can create a new file via touch and it gets created > with the correct context > > 268 roland> ls -Z foo > -rw-rw-r--. roland roland unconfined_u:object_r:user_home_t:s0 foo > 269 roland> ls -Zad . > drwxr-xr-x. roland roland system_u:object_r:user_home_dir_t:s0 . > > But again, if I run restorecon, it gets converted to default_t. > > I realize the whole NIS/NFS thing makes this problematic on the clients, > but all of the above is on the server. I was hoping to get the file > contexts fixed up, but even if I can get it to stop converting > everything back to default_t, I haven't got a clue about all the other > contexts I need to set (e.g., ssh_home_t for .ssh, but what else) and > then I fear they will just get reset, too. > > So, what's going on here and how do I stop it? Then after that, how do I > go about fixing all the default_t under my home directory to be what > they should be. > > roland > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
