Eni and I are resuscitating the NY Times scraping project and we want to get some new data. So I’m using the good ol’ trustus account that Olivia, Emily and I used in Tyler’s course last spring.
I’ve encountered this annoyance before:
~$ ssh -Y trustus@cs trustus@cs's password: Warning: No xauth data; using fake authentication data for X11 forwarding. Last login: Wed Jan 30 12:05:09 2013 from 149.130.206.39 /usr/bin/xauth: timeout in locking authority file /students/trustus/.Xauthority
The timeout is about 20 seconds. Of course the culprit is SELinux, as we see in the user-friendly error messages in /var/log/audit/audit.log:
type=AVC msg=audit(1359565919.330:411758): avc: denied { write } for pid=4001 comm="xauth" name="trustus" dev=dm-2 ino=1209019 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
Let’s compare some home directories:
[root@tempest log] ls -lZd /home/anderson/ drwxr-x--x. anderson anderson unconfined_u:object_r:user_home_dir_t:s0 /home/anderson/ [root@tempest log] ls -lZd /students/edavis5/ drwxr-x--x. edavis5 edavis5 system_u:object_r:user_home_dir_t:s0 /students/edavis5/ [root@tempest log] ls -lZd /students/trustus/ drwxr-x--x. trustus trustus system_u:object_r:home_root_t:s0 /students/trustus/ [root@tempest log]
Clearly that home_root_t is the problem. Only /home and /students are supposed to have that; their contents should be user_home_t. Let’s look more carefully at all the home directories:
[root@tempest log] ls -lZ /home|sort -k4 drwxr-x--x. cs110s12 cs110s12 system_u:object_r:home_root_t:s0 appinv-stats drwxrwx--x. mjust mjust system_u:object_r:home_root_t:s0 mjust drwx------. root root system_u:object_r:lost_found_t:s0 lost+found drwxr-x--x. anderson anderson unconfined_u:object_r:user_home_dir_t:s0 anderson drwxrwxr-x. 91 tomcat unconfined_u:object_r:user_home_dir_t:s0 apache-tomcat-5.5.26 . . # Remainder all same: unconfined_u:object_r:user_home_dir_t:s0 [root@tempest log] ls -lZ /students |sort -k4 drwxr-x--x. cdefries cdefries system_u:object_r:home_root_t:s0 cdefries drwxr-x--x. emilyuki emilyuki system_u:object_r:home_root_t:s0 emilyuki drwxr-x--x. forsale forsale system_u:object_r:home_root_t:s0 forsale drwxr-x--x. mkorpusi mkorpusi system_u:object_r:home_root_t:s0 mkorpusi drwxr-x--x. raw raw system_u:object_r:home_root_t:s0 raw drwxr-x--x. skyteam skyteam system_u:object_r:home_root_t:s0 skyteam drwxr-x--x. theclean theclean system_u:object_r:home_root_t:s0 theclean drwxr-x--x. thejolly thejolly system_u:object_r:home_root_t:s0 thejolly drwxr-x--x. trustus trustus system_u:object_r:home_root_t:s0 trustus drwx------. root root system_u:object_r:lost_found_t:s0 lost+found dr-x--x--x. 2sustain 2sustain system_u:object_r:user_home_dir_t:s0 2sustain dr-xr-x--x. 8ninjas8 8ninjas8 system_u:object_r:user_home_dir_t:s0 8ninjas8 drwxr-x--x. aaaron aaaron system_u:object_r:user_home_dir_t:s0 aaaron drwxr-x--x. aadidako aadidako system_u:object_r:user_home_dir_t:s0 aadidako drwxr-x--x. aahiable aahiable system_u:object_r:user_home_dir_t:s0 aahiable . . # 1000 like this . drwxr-x--x. zsutton zsutton system_u:object_r:user_home_dir_t:s0 zsutton drwxr-x--x. zyue zyue system_u:object_r:user_home_dir_t:s0 zyue -rw-------. root root unconfined_u:object_r:quota_db_t:s0 aquota.group -rw-------. root root unconfined_u:object_r:quota_db_t:s0 aquota.user drwxr-x--x. aali3 aali3 unconfined_u:object_r:user_home_dir_t:s0 aali3 drwxr-x--x. aarora aarora unconfined_u:object_r:user_home_dir_t:s0 aarora drwxr-x--x. ablige ablige unconfined_u:object_r:user_home_dir_t:s0 ablige drwxr-x--x. absz2012 absz2012 unconfined_u:object_r:user_home_dir_t:s0 absz2012 . . # 300 like this .
The four fields are user, role, type, and security level. I’d love to understand this stuff, but no time. The restorecon command fixes only the type unless you use the -F option, so perhaps that’s the important one.
Focusing on the type, then, I nervously pulled the trigger on ‘restorecon -pR /students/trustus/’. That changed the type of all the files to match the other student directories:
[root@tempest students] ls -lZd trustus/ drwxr-x--x. trustus trustus system_u:object_r:user_home_dir_t:s0 trustus/ [root@tempest students] ls -lZ trustus/ -rw-rw----. trustus trustus system_u:object_r:user_home_t:s0 59508062.json drwxrwxr-x. trustus trustus system_u:object_r:user_home_t:s0 ai_ek drwxrwx---. trustus trustus system_u:object_r:user_home_t:s0 code . .
And now I can ssh in without delay, so, problem solved.
I think that the above difference in user type comes from when the account was created. In /students, old-timers like choover, cgrote, and dgerr are all system_u; conversely students added recently all appear to be unconfined_u. Probably the dividing line is when we copied everything from puma to tempest. According to Sec. 3.3 of the RHEL SELinux User Guide , unconfined_u is the default. I assume the system_u’s came from the copying process from puma, and the ‘restorecon -R -v /students’ that Scott did on 2/21/2012 did not change them to the default because the -F flag was not specified. I’d bet that it’s not important, but I’m not certain.
Now we should probably restorecon these accounts in /students (probably most are no longer used): cdefries, emilyuki, forsale, mkorpusi, raw, skyteam. theclean, thejolly. Ditto for appinv-stats and mjust in /home, although they’re not used either. I’ll do that in a couple days after I use trustus a bit and am sure everything’s OK.
Update Feb. 22, 2013
Everything was fine with trustus after I made the above change, so I also restorecon-ed all the accounts mentioned in the previous paragraph. Now all the “type” fields in /home and /students are as they should be; the only discrepancies are for system files such as lost+found and aquota.*, as you’d expect.
The first field, “user”, is still non-uniform. Accounts copied from puma are system_u (I read somewhere that this is inherited from the copying process). New accounts are unconfined_u. I think this is fixable using “restorecon -F”. However, according to the RHEL 6 SELinux User Guide, “Type Enforcement is the main permission control used in SELinux targeted policy. For the most part, SELinux users and roles can be ignored.” I don’t want to risk a disaster messing with something I don’t understand, so I’m going to leave it alone.