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
--
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD RL Enterprises
roland@xxxxxxxxxxx 6818 Madeline Court
roland@xxxxxxxxxxxxx Brooklyn, NY 11220
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
