Bug 445944 - restorecon doesn't set context on /var/run/sm-client.pid
restorecon doesn't set context on /var/run/sm-client.pid
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: SELinux
Depends On:
  Show dependency treegraph
Reported: 2008-05-09 22:32 EDT by Tim Bird
Modified: 2008-05-27 16:12 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-27 16:12:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim Bird 2008-05-09 22:32:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20071030 Fedora/ Firefox/

Description of problem:
If you run 'service sendmail status', you see the error message:
sm-client dead but pid file exists

This is caused by a failure of sendmail to be able to write the pid file
for sm-client on startup.

When sendmail is started (via /etc/rc.d/init.d/sendmail) it creates the
file /var/run/sm-client.pid.  The init script runs /sbin/restorecon on the file
but this operation has no effect.  After sendmail is started, the pid file
is 0 bytes, resulting in the error above.  During the initialization, I see
a message in /var/log/messages about sendmail being denied access to
the sm-client.pid file, due to it being default_t context.

I think this bug has been kicking around for quite a while.  There are previous
bug reports relating to the security context on /var/run/sm-client.pid dating
back several years.  Various workarounds seem to have been used to get
around the problem in the past, but I can find no mention of a possible bug
in restorecon or the policy which prevents setting the correct context.
(Which is my best guess for the source of the error).

Here are relevant entries from the 'targeted' policy, which I believe
I'm using:

 $find /etc/selinux/targeted -type f | xargs grep sm-client

/etc/selinux/targeted/contexts/files/file_contexts:/var/run/sm-client\.pid     --       system_u:object_r:sendmail_var_run_t:s0
/etc/selinux/targeted/modules/active/file_contexts:/var/run/sm-client\.pid     --       system_u:object_r:sendmail_var_run_t:s0
Binary file /etc/selinux/targeted/modules/active/base.pp matches
/etc/selinux/targeted/modules/active/file_contexts.template:/var/run/sm-client\.pid     --      system_u:object_r:sendmail_var_run_t:s0

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. service sendmail restart
2. ls -Z /var/run/sm-client.pid

1. ls -Z /var/run/sm-client.pid
2. /sbin/restorecon /var/run/sm-client.pid
3. ls -Z /var/run/sm-client.pid

Actual Results:
1. ls -Z /var/run/sm-client.pid
-rw-r--r--  smmsp smmsp system_u:object_r:default_t:s0   /var/run/sm-client.pid
2. /sbin/restorecon /var/run/sm-client.pid
3. ls -Z /var/run/sm-client.pid
-rw-r--r--  smmsp smmsp system_u:object_r:default_t:s0   /var/run/sm-client.pid

Expected Results:
I epxected the file /var/run/sm-client.pid to be relabeled with security context

Additional info:
Comment 1 Tim Bird 2008-05-27 14:56:05 EDT
Here is some additional information:

I was using a symlink in my /var setup on my box, and this looks like it was
the cause of the problem.  Specifically, I had the following setup:

/var symlinked to /a/var  (where a /a was another file system)
Thus, the realpath of /var/run/sm-client.pid was /a/var/run/sm-client.pid.

After changing reverting back to having /var on the / file system, restorecon

This is probably a newbie error on my part (I suspect that restorecon can't
handle crossing symlinks), but it would have been nice to have gotten some kind
of indication of the problem.

The way restorecon currently works, you can't place /var on another file
system and use selinux without a lot of configuration changes.  I'll leave
it to you whether this is a bug or not.
Comment 2 Daniel Walsh 2008-05-27 16:12:14 EDT
If you used a bind mount rather then a link it would have worked.  You also
could have labeled /a as var_t.

But restorecon translates explicit paths so it will figure out the "correct"
path for an object.  This prevents symbolic link attacks such as linking
~/myshadow to /etc/shadow and tricking restorecon to fix the context.

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