<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body ><div>For reasons I don't understand, the install labelled /home with (I think, I'm offsite with no access) auto_fs_t as it is a mount point for autofs.</div><div><br></div><div>Roland</div>--<div>Roland Roberts, PhD</div><div>6818 Madeline Court</div><div>Brooklyn, NY 11220</div><br><br><br>-------- Original message --------<br>From: Daniel J Walsh <dwalsh@redhat.com> <br>Date: 05/28/2013 8:33 AM (GMT-05:00) <br>To: Roland Roberts <roland@astrofoto.org> <br>Cc: Dominick Grift <dominick.grift@gmail.com>,selinux@lists.fedoraproject.org <br>Subject: Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting
user_home_dir_t to detault_t <br> <br><br>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>On 05/28/2013 08:03 AM, Roland Roberts wrote:<br>> Yet normally /home is home_root_t. And in my case /data is a mount point<br>> for other things; the actual disk is mounted at /data/home, so I thought I<br>> was doing the equivalent of what the man page says.<br>> <br>> Roland -- Roland Roberts, PhD 6818 Madeline Court Brooklyn, NY 11220<br>> <br>> <br>> <br>> -------- Original message -------- From: Dominick Grift<br>> <dominick.grift@gmail.com> Date: 05/28/2013 4:13 AM (GMT-05:00) To: Roland<br>> Roberts <roland@astrofoto.org> Cc: selinux@lists.fedoraproject.org Subject:<br>> Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting <br>> user_home_dir_t to detault_t<br>> <br>> <br>> On Mon, 2013-05-27 at 19:01 -0400, Roland Roberts wrote:<br>> <br>> SELinux contexts for /home are treated a bit differently than other <br>> locations.<br>> <br>> Try instead: (from: man semanage):<br>> <br>>> For home directories under top level directory, for example /disk6/home, <br>>> execute the following commands. # semanage fcontext -a -t home_root_t<br>>> "/disk6" # semanage fcontext -a -e /home /disk6/home # restorecon -R -v<br>>> /disk6<br>> <br>> <br>>> I'm trying to clean up selinux contexts and having trouble. The system is<br>>> a new install of Fedora 18, but the home directories have been preserved<br>>> for a long time. Because the system runs boot on raid-1, it was installed<br>>> as Fedora 17 and then I used fedup to move to Fedora 18.<br>>> <br>>> My home directories are automounted via NFS and an NIS map. I mount them <br>>> on the clients with an explicit context:<br>>> <br>>> 270 roland> ypcat auto.home <br>>> -rw,soft,intr,tcp,context="system_u:object_r:user_home_t:s0" <br>>> archos.rlent.pnet:/data/home/&<br>>> <br>>> However, my troubles right now are confined to the server.<br>>> <br>>> The real home directory is /data/home so /data/home/roland is mounted on <br>>> /home/roland. All clients see the same mount point, even the server <br>>> remounts this way.<br>>> <br>>> Most of the selinux context information is wrong, probably because some <br>>> of these files have been hanging around roughly since RedHat 3.0.3. Yes, <br>>> really. Although the content has surely changed (e.g., .bashrc).<br>>> <br>>> To get started, I've done this<br>>> <br>>> semanage fcontext -a -t home_root_t /data/home semanage fcontext -a -t<br>>> user_home_dir_t '/data/home/(.*)' semanage fcontext -a -t lost_found_t<br>>> /data/home/lost+found restorecon -v -R /data/home<br>>> <br>>> That gave the surprising result of doing absolutely nothing. So I <br>>> brute-forced it and did<br>>> <br>>> semanage fcontext -a -t home_root_t /data/home semanage fcontext -a -t<br>>> lost_found_t /data/home/lost+found for D in $LIST; do semanage fcontext<br>>> -a -t user_home_dir_t /data/home/$D; done restorecon -v -R /data/home<br>>> <br>>> The above did not work for the lost+found directory. I haven't figured <br>>> out why. I tried deleting all the contexts I had set and starting over <br>>> and I tried setting the context just on lost+found repeatedly to no <br>>> avail. lost+found remains default_t.<br>>> <br>>> Next, I log in via ssh to my user account. Since I have X forwarding <br>>> turned on, this results in an .Xauthority file being created. If I run <br>>> (as root, from another window) restorecon, I get this<br>>> <br>>> [root@archos ~]# cd /data/home/roland [root@archos roland]# restorecon -v<br>>> -R /data/home/roland restorecon reset /data/home/roland/.Xauthority<br>>> context <br>>> unconfined_u:object_r:xauth_home_t:s0->unconfined_u:object_r:default_t:s0<br>>><br>>><br>>> <br>So the file was created with the correct context, but it gets zapped<br>>> with restorecon. I can create a new file via touch and it gets created <br>>> with the correct context<br>>> <br>>> 268 roland> ls -Z foo -rw-rw-r--. roland roland<br>>> unconfined_u:object_r:user_home_t:s0 foo 269 roland> ls -Zad . <br>>> drwxr-xr-x. roland roland system_u:object_r:user_home_dir_t:s0 .<br>>> <br>>> But again, if I run restorecon, it gets converted to default_t.<br>>> <br>>> I realize the whole NIS/NFS thing makes this problematic on the clients, <br>>> but all of the above is on the server. I was hoping to get the file <br>>> contexts fixed up, but even if I can get it to stop converting everything<br>>> back to default_t, I haven't got a clue about all the other contexts I<br>>> need to set (e.g., ssh_home_t for .ssh, but what else) and then I fear<br>>> they will just get reset, too.<br>>> <br>>> So, what's going on here and how do I stop it? Then after that, how do I <br>>> go about fixing all the default_t under my home directory to be what they<br>>> should be.<br>>> <br>>> roland<br>>> <br>> <br>> <br>> <br>> <br>> -- selinux mailing list selinux@lists.fedoraproject.org <br>> https://admin.fedoraproject.org/mailman/listinfo/selinux<br>> <br><br>In this case you want to label /data/home as equivalent to /home<br>and you probably want to label data with a label that most apps can read like<br>usr_t.<br><br><br># semanage fcontext -a -t usr_t '/data(/.*)?'<br># semanage fcontext -a -e /home /data/home<br><br><br><br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.13 (GNU/Linux)<br>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/<br><br>iEYEARECAAYFAlGkpAIACgkQrlYvE4MpobMKdgCgyvOOSlMo+7wSO7qB52SMHFRT<br>vUwAoIXc15OzcmadYZC+NANqMxKRSCve<br>=EBci<br>-----END PGP SIGNATURE-----<br></body>