Bug 720122

Had to keep adding to the policy to get apcupsd to run correctly using an UPS with a serial port for monitory. 

Yes, I know serial ports are going the way of the dodo, but the UPS is working, not cheap, and until it fails, there is no reason to replace it.

The finale version of the policy is:


module localApcupsd 1.0;

require {
        type var_lock_t;
        type apcupsd_t;
        class file { read unlink open };
}

#============= apcupsd_t ==============
allow apcupsd_t var_lock_t:file { read unlink open };

monitory -> monitoring

As a note, this just stated happening with the update to selinux-policy-targeted-3.9.16-32.fc15.noarch. Prior to that apcupsd worked with the serial port just fine.

John,
could you turn on full auditing system


# echo "-w /etc/shadow -p w" >> /etc/audit/audit.rules 
# service auditd restart

and disable your local policy

# semodule -d localApcupsd

and retest it.

That will have to wait a couple of hours but will do.

OK. I give up. It is working just fine. Any explanation available?

I did:
# echo "-w /etc/shadow -p w" >> /etc/audit/audit.rules 
# service auditd restart
# semodule -d localApcupsd
# systemctl restart apcupsd.service
# systemctl status apcupsd.service
apcupsd.service - LSB: apcupsd daemon
          Loaded: loaded (/etc/rc.d/init.d/apcupsd)
          Active: active (running) since Mon, 11 Jul 2011 19:37:28 -0400; 15s ago
         Process: 9142 ExecStop=/etc/rc.d/init.d/apcupsd stop (code=exited, status=0/SUCCESS)
         Process: 9154 ExecStart=/etc/rc.d/init.d/apcupsd start (code=exited, status=0/SUCCESS)
        Main PID: 9161 (apcupsd)
          CGroup: name=systemd:/system/apcupsd.service
                  └ 9161 /sbin/apcupsd -f /etc/apcupsd/apcupsd.conf

Which is exactly what I would expect.

I removed the "-w /etc/shadow -p w" from  /etc/audit/audit.rules and restarted auditd and  apcupsd and still fine. Then I removed the policy 
# semodule -r localApcupsd
and restarted apcupsd and still all OK.

So I am stumped. I am not in the habit of filing bugs to have people chase phantoms, but the AVC was real and apcupsd really would not start correctly.

What is the current context of "LCK..ttyS0"?

# ls -Z /run/lock/LCK*
-rw-r--r--. root root system_u:object_r:apcupsd_lock_t:s0 /run/lock/LCK..ttyS0

I would guess one run of apcupsd ran without transition for some reason,causing the LCK file to be mislabelled.  Perhaps you ran it directly?  

Then later the file got destroyed recreated with the correct context.  Which you are seeing now.  If you can recreate this please reopen the bug.

Did not ever start apcupsd directly. When I do stop, start, or restart, I use systemctl or one of the init.d scripts.

This occurred when I did an update using yum. apcupsd was running normally. Yum did the update and a new selinux policy came down. At the end of the update, I got an email from a apcupsd slave server that it had lost contact with the master. When I checked the status of apcupsd on the master, it had exited. When I tried to restart, it would not start and sealert gave me the original report of the denial to LCK..ttyS0.

Oh well, glad it is working.

Meaning something in the update might have modified the apcupsd process,  was their an apcupsd package update?

Yes there was.

# diff rpms.fc15.201107091148 rpms.test | grep apc
< apcupsd-cgi~Fedora Project~x86-09.phx2.fedoraproject.org~7.fc15~apcupsd-cgi-3.14.8-7.fc15
< apcupsd~Fedora Project~x86-09.phx2.fedoraproject.org~7.fc15~apcupsd-3.14.8-7.fc15
< apcupsd-gui~Fedora Project~x86-09.phx2.fedoraproject.org~7.fc15~apcupsd-gui-3.14.8-7.fc15
> apcupsd-cgi~Fedora Project~x86-07.phx2.fedoraproject.org~8.fc15~apcupsd-cgi-3.14.8-8.fc15
> apcupsd~Fedora Project~x86-07.phx2.fedoraproject.org~8.fc15~apcupsd-3.14.8-8.fc15
> apcupsd-gui~Fedora Project~x86-07.phx2.fedoraproject.org~8.fc15~apcupsd-gui-3.14.8-8.fc15