Bug 674727 - SELinux is preventing /sbin/apcupsd from read, write access on the chr_file hiddev0.
Summary: SELinux is preventing /sbin/apcupsd from read, write access on the chr_file h...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Eric Paris
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:4c58cef4c6d...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-03 03:32 UTC by Julian C. Dunn
Modified: 2011-10-12 17:49 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-12 17:49:42 UTC
Type: ---


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 710739 0 unspecified CLOSED SELinux is preventing /sbin/apcupsd from read access on the lnk_file /var/lock 2021-02-22 00:41:40 UTC

Internal Links: 710739

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.


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