When I ssh into a server running restorecond and I'm the only user, it isn't updating correctly. For example, if I "mkdir public_html", it gets the context from the parent directory (user_home_t). If I open a second ssh connection as a different user (while the first user is still logged in), suddenly the first user's public_html gets the correct context (httpd_sys_content_t). The second ssh has to use a different login for this to happen; if I ssh as the same user, nothing happens. Steps: $ ssh cmadams@server $ mkdir public_html $ ls -Zd public_html drwxr-xr-x cmadams Staff user_u:object_r:user_home_t:s0 public_html In another local window: $ ssh cma@server Back in the first window: $ ls -Zd public_html drwxr-xr-x cmadams Staff user_u:object_r:httpd_sys_content_t:s0 public_html
My server has a serial console hooked up; I have tested this by: - disabling the getty on the serial port - running a root shell directly on the serial port (so no login) - running "restorecond -d" from that port So, at this point there are no users logged in (as far as utmp is concerned). I ssh in as a regular user, and all I get from the restorecond debugging output is: wd=64 mask=2 cookie=0 len=0 wd=64 mask=32768 cookie=0 len=0 The correct utmp entry was definately written; I see it with "w" (and even "dump-utmp /var/run/utmp").
Okay, I found the problem: the utmp watcher only returns that there was a "change" when there was a pre-existing list. The first user will never trigger a change. Patch attached. FYI: this is also a problem for Fedora and should be fixed there as well.
Created attachment 438511 [details] fix handling the first login
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Fixed in policycoreutils-1.33.12-14.10.el5
The bug can be still reproduced with current policycoreutils version: [root ~]# rpm -q policycoreutils policycoreutils-1.33.12-14.13.el5 [root ~]# service restorecond status restorecond (pid 3650) is running... ######### I'll create public_html directory in a user's home [root ~]# su bobo [bobo root]$ cd ~ [bobo ~]$ ls -laZ | grep public_html [bobo ~]$ mkdir public_html ######### Because only one user is logged in, the dir has wrong context [bobo ~]$ w 07:37:04 up 2:48, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/1 dhcp-25-142.brq. 07:32 0.00s 0.08s 0.00s w [bobo ~]$ ls -laZ | grep public_html drwxrwxr-x bobo bobo root:object_r:user_home_t public_html ######### The moment another user connected via ssh from other terminal, ######### the context switched to correct one. [bobo ~]$ w 07:36:00 up 2:47, 2 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT bobo pts/0 dhcp-25-142.brq. 07:35 9.00s 0.03s 0.03s -bash root pts/1 dhcp-25-142.brq. 07:32 0.00s 0.09s 0.01s w [bobo ~]$ ls -laZ | grep public_html drwxrwxr-x bobo bobo user_u:object_r:httpd_sys_content_t public_html
Switching back to ON_QA.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1344.html