From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071030 Fedora/2.0.0.8-2.fc8 Firefox/2.0.0.8 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): selinux-policy-targeted-3.0.8-98.fc8 How reproducible: Always Steps to Reproduce: 1. service sendmail restart 2. ls -Z /var/run/sm-client.pid or 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 system_u:object_r:sendmail_var_run_t Additional info:
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 worked. 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.
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.