SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting user_home_dir_t to detault_t

[Roland Roberts]

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 at archos ~]# cd /data/home/roland
[root at 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

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland at rlenter.com                            6818 Madeline Court
roland at astrofoto.org                           Brooklyn, NY 11220