Bastien Nocera wrote: > Heya, > > Here's a big patch to add user tracking to the device object. Only the > user/process that called ClaimDevice can subsequently use that device.
I didn't know that dbus exposed user information like it does. Is it secure? If so, it seems fine. I previously thought we'd have to use ConsoleKit to determine the user. Any pros/cons of each approach? > I'm also thinking about adding PolicyKit to the whole mix. Should I make > PolicyKit a hard dependency, or a compile-time one? I think it's fine to be a hard dependency. > So I think that we should: > - kill Claim/Release, and claim/release devices when we actually need > access to the hardware > - add a single call to change the UID to work on, we would (by default, > and probably more finely-grained with PolicyKit support) only allow root > to change the active UID, and single users to set it to theirs. > > This would allow us to fix the second use cases. With PolicyKit support > we could fix the user management tool to not have to run as root, as > well as the first use case. Sounds fine. Only thing that springs to mind is what happens if you set one user, load some print data, then set another user. But I can't see any reason for breakage. I think such an interface would actually allow you to load enrollment data for one user, and then verify it against another user's print. Not sure if that is useful to anyone, but perhaps we can label it as a feature ;) Thanks, Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
