Bug 674727

Summary: SELinux is preventing /sbin/apcupsd from read, write access on the chr_file hiddev0.
Product: [Fedora] Fedora Reporter: Julian C. Dunn <jdunn>
Component: kernelAssignee: Eric Paris <eparis>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: dwalsh, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:4c58cef4c6d457e10212fb68e703005b42b4424e0180661ee050f60e46cba26e
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-12 17:49:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Julian C. Dunn 2011-02-03 03:32:15 UTC
SELinux is preventing /sbin/apcupsd from read, write access on the chr_file hiddev0.

*****  Plugin device (91.4 confidence) suggests  *****************************

If you want to allow apcupsd to have read write access on the hiddev0 chr_file
Then you need to change the label on hiddev0 to a type of a similar device.
Do
# semanage fcontext -a -t SIMILAR_TYPE 'hiddev0'
# restorecon -v 'hiddev0'

*****  Plugin catchall (9.59 confidence) suggests  ***************************

If you believe that apcupsd should be allowed read write access on the hiddev0 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep apcupsd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:apcupsd_t:s0
Target Context                system_u:object_r:device_t:s0
Target Objects                hiddev0 [ chr_file ]
Source                        apcupsd
Source Path                   /sbin/apcupsd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           apcupsd-3.14.8-3.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-25.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23
                              16:04:50 UTC 2010 x86_64 x86_64
Alert Count                   2
First Seen                    Wed 02 Feb 2011 10:28:48 PM EST
Last Seen                     Wed 02 Feb 2011 10:28:49 PM EST
Local ID                      95185c17-442b-430c-8dc4-ccd11479ba6a

Raw Audit Messages
type=AVC msg=audit(1296703729.861:30439): avc:  denied  { read write } for  pid=1617 comm="apcupsd" name="hiddev0" dev=devtmpfs ino=104453 scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file


type=SYSCALL msg=audit(1296703729.861:30439): arch=x86_64 syscall=open success=no exit=EACCES a0=9140b8 a1=102 a2=c8 a3=8 items=0 ppid=1 pid=1617 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=apcupsd exe=/sbin/apcupsd subj=system_u:system_r:apcupsd_t:s0 key=(null)

Hash: apcupsd,apcupsd_t,device_t,chr_file,read,write

audit2allow

#============= apcupsd_t ==============
allow apcupsd_t device_t:chr_file { read write };

audit2allow -R

#============= apcupsd_t ==============
allow apcupsd_t device_t:chr_file { read write };

Comment 1 Miroslav Grepl 2011-02-03 11:29:35 UTC
For some reason this device got created with the wrong label. What is the current label

# ls -lZ /dev/hiddev0

Should be 

# matchpathcon /dev/hiddev0
/dev/hiddev0	system_u:object_r:usb_device_t:s0


If the label is still "device_t" then

# restorecon -R -v /dev/hiddev0

will fix it and any chance you can reproduce it again?

Comment 2 Julian C. Dunn 2011-02-11 02:39:58 UTC
It's actually /dev/usb/hiddev0 and it's already:

jupiter:/dev$ ls -lZ /dev/usb/hiddev0
crw-------. root root system_u:object_r:usb_device_t:s0 /dev/usb/hiddev0

This error happens very infrequently. I must admit that I have a very odd use case. I have an APC Back-UPS uninterruptible power supply unit that behaves strangely with Fedora 14. Basically it keeps doing a USB disconnect and connect, and then this error occurs after about 50 iterations.

Comment 3 Daniel Walsh 2011-02-11 16:12:32 UTC
It looks to me like  a race condition.  The kernel is creating the device and udev is fixing the label, but occasionally  apcupsd gets the device before it is relabeled.  Is this causing anything to break?

Comment 4 Julian C. Dunn 2011-02-13 01:41:24 UTC
There doesn't seem to be any operational impact, no.

Comment 5 Eric Paris 2011-10-12 17:49:42 UTC
closing this as it is fixed in F16 with the implementation or filename trans rules.