SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting user_home_dir_t to detault_t
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
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@lists.fedoraproject.org
-
Dominick Grift -
Roland Roberts