Bug 623708 - restorecond not working when just one user logged in
Summary: restorecond not working when just one user logged in
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: policycoreutils
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Michal Trunecka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-12 15:12 UTC by Chris Adams
Modified: 2014-09-30 23:33 UTC (History)
5 users (show)

Fixed In Version: policycoreutils-1.33.12-14.10.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-30 23:22:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
fix handling the first login (629 bytes, patch)
2010-08-12 19:16 UTC, Chris Adams
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1344 0 normal SHIPPED_LIVE policycoreutils bug fix update 2013-09-30 21:12:49 UTC

Description Chris Adams 2010-08-12 15:12:39 UTC
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

Comment 1 Chris Adams 2010-08-12 19:01:47 UTC
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").

Comment 2 Chris Adams 2010-08-12 19:15:59 UTC
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.

Comment 3 Chris Adams 2010-08-12 19:16:26 UTC
Created attachment 438511 [details]
fix handling the first login

Comment 4 RHEL Program Management 2010-08-13 18:36:31 UTC
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.

Comment 6 RHEL Program Management 2012-06-12 01:16:52 UTC
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.

Comment 7 RHEL Program Management 2013-04-17 09:08:06 UTC
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.

Comment 9 Miroslav Grepl 2013-05-16 21:08:20 UTC
Fixed in policycoreutils-1.33.12-14.10.el5

Comment 11 Michal Trunecka 2013-06-26 11:45:08 UTC
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

Comment 12 Miroslav Grepl 2013-06-27 11:28:27 UTC
Switching back to ON_QA.

Comment 15 errata-xmlrpc 2013-09-30 23:22:33 UTC
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


Note You need to log in before you can comment on or make changes to this bug.