On Sun, 2008-05-18 at 12:40 +0100, Daniel Drake wrote: > 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?
It is secure, we can then use PolicyKit to tighten access to certain calls. > > 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. Cool. > > 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. That would only happen if a particular user was allowed to set a UID as the current one that wasn't his. > 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 ;) I'll get started on that then. Thanks! _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
