On 01/03/2008 07:07 AM, Tim Waugh wrote:
The problem I'm trying to solve is described in bug #424331: https://bugzilla.redhat.com/show_bug.cgi?id=424331
The background is that HPLIP uses libusb to communicate with HP USB printers, and both the printing system (running in group 'lp') and the current console user (or uses) need access in that way. The console user needs this access for ink-level checking and other status functions provided by the hp-toolbox program, and potentially for using the in-built scanner with libsane.
When the printer is plugged in, the device node that libusb uses for it is in /dev/bus/usb/.../... and we want it to have group read/write access for 'lp', and user read/write access for each console user.
The intention is to have udev rules set the group ownership to 'lp', and to grant group read/write permissions, and to have the HAL rules grant a 'rw' ACL for each console user. I originally described this approach here:
http://cyberelk.net/tim/2007/10/04/hplip-device-permissions-with-consolekit/
It worked well, but a recent kernel update seems to have revealed a race condition. The ACL is granted (by hal-acl-tool) before the 'MODE=...' udev rule is applied, and this ordering messes up the ACL permissions (either the ACL mask or the group permissions end up being restricted).
The problem boils down to this: How can I ensure that the ACL is granted *after* the mode permissions have been set, i.e. after the udev rules have completed, not before?
If you know what the incorrect udev permissions are, you could just sleep until they change.