Currently /usr/sbin/lockdev has an ordinary sbin_t SELinux type. As a result, lockdev-enabled programs need special permissions to read/add/remove the lock files in /var/lock. This is IMHO wrong - it would be much more consistent to transition into a lockdev_t domain on executing /usr/sbin/lockdev and then allow the lockdev_t, not the original domain to access /var/lock.
I need more info? What is failing here? It might be a problem if apps transitioned to lockdev, and you needed to give lockdev access to all /var/lock files. Dan
Programs that are supposed to give users access to certain serial devices (including minicom and gphoto2) are compiled against the liblockdev library that implements locking using a setgid helper program /usr/sbin/lockdev (that allows arbitrary users to install/remove locks in the /var/locks directory, possibly with some appropriate permission checks). Note that the users themselves do not have write permissions to /var/locks (which is the whole point). Now enters SELinux. Suddenly users can not touch /var/locks even with the help of a setgid binary. As a result, minicon, gphoto2 (and other similar programs, such as efax and kandy once bug 79615 and bug 84143 are fixed) are no longer able to lock the serial devices when ran by an ordinary user. Basically, the whole point of the /usr/sbin/lockdev binary is a limited privilegde elevation and it needs to be supported under SELinux as well.
Thanks I will look into adding SELinux support to it. Dan
Added fixes to selinux-policy-strict-1.18.2-3 Tested it out with minilog. Please try it out. Dan