Bug 623708

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 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