ConsoleKit vs udev, ACLs getting lost

[Chuck Ebbert]

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.