Vasily Khoruzhick wrote: > Hi, Daniel. If I understand correctly, Fprintd should be launched for every > user (account) who wants to work with fingerprinting, am I right? Actually, > its dbus question, but I know nobody who can know answer on this question
I don't know much about D-Bus either, but I feel it should be system wide, and the red hat guys did not shoot me down for this. This email might help you, we had just a couple of private discussions to kickstart fprintd, this is really the beef of it though: --------------------------------------- On Tue, 2008-03-04 at 22:27 +0000, Daniel Drake wrote: > > OK. I read through some of that. fprintd would link against libpolkit, > > would use ConsoleKit to identify the user credentials, and would then > > ask PolicyKit to check permissions. Makes sense. Right, you would actually just link against libpolkit-dbus and use the convenience API to create PolKitCaller objects. See below also for a much simpler solution. >> > > Right, ideally fprintf would also ship a hal fdi file so it's easy for >> > > apps to locate the fingerprint readers. Once an app finds a finger print >> > > reader it can connect to your D-Bus service. > > > > That sounds doable. > > >> > > PolicyKit would just access it via PAM I think. > > > > PAM has proven not very good at complex login scenarios like this. > > Especially when you want to perhaps give visual feedback of the scan, or > > combine both password input with fingerprint scanning and allow the user > > to do either. This problem is of course in a different barrel of fish > > but it looks like we may take the approach of shortcutting PAM in some > > apps in order to get decent fingerprint scanning. It's true that PAM is rather limited in the interactions it allows between the app (e.g. gdm, gnome-screensaver, the polkit auth dialog, etc.) but I think it's good enough for just authentication isn't it? It's a good question if we can augment the PAM interface so the apps we care about (same list as above) can show more information. I think that's possible, maybe your D-Bus daemon just emits a signal and the app can connect and get information out-of-band. I don't know. I know Jon have looked a lot more into this than I have so I'll let him reply. > > - How can we achieve the systemwide daemon implementation nicely? This can be achieved through system bus activation; that feature landed in the 1.1.x series of D-Bus and will appear in the stable 1.2.x series out Real Soon Now(tm). All major distros are shipping 1.1.x I think. See http://lists.freedesktop.org/archives/dbus/2007-June/007874.html > > - How usable is my current daemon implementation when considering > > moving towards using HAL/PolicyKit/ConsoleKit? Will I have to pretty > > much start again, or is it more of a case of adding on the > > HAL/PK/CK parts to my existing work? Should be as easy as adding checks just when you receive a method call via D-Bus. In fact, if you use the convenience interface it's a one-liner, just something like result = polkit_check_auth (pid, "net.reactivated.fprint.can-check-fingerprint"); if (result == 0) { /* throw D-Bus expection */ goto out; } where you get the pid from the sender of the message. See http://hal.freedesktop.org/docs/PolicyKit/polkit-polkit-simple.html#polkit-check-auth Of course this makes lots of bus roundtrips so if you care about performance (not sure it's a problem though) there's a lot of other API to cache this. But for starters just using polkit_check_auth() is good enough I think. Cheers, David --------------------------------------- > P.S. I'm finishing storage interface (generic for all storage-types) and > local > file storage implementation for Fprintd, in general, local file storage > duplicates one in libfprint, but it supports "user-switching", i.e. root can > retrieve prints of any user. Maybe it will be better to extend storage in > libfprint? I'm happy to merge your fprintd work with only little review, given that you're putting the time in and it'll be a while before I can do so. So if it has to be reimplemented, then I can settle with that for now. I'd question why, but the code will probably answer that. I'm still not keen on overcomplicating libfprint with storage stuff. But maybe I'll change my mind after seeing how things work out in fprintd... think of fprintd still as a prototype project :) Thanks! Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
