On Tuesday 26 May 2009 19:04:35 David Zeuthen wrote: > But it's the other way around, the D-Bus interfaces are what the daemon > exposes. The libpolkit-agent.so is just a small library that provides > >[...] > > Keep in mind that PolicyKit proper does not care about PAM at all; in > fact, the authentication agent could be a simple program that just > provides an user experience with simple "Deny/Confirm" buttons instead > of requiring authentication.
Ok, cool stuff > > This is actually _a good thing_ since for some devices you want a user > experience like that (e.g. "Deny/Confirm" instead of passwords etc.). It > also allows us to switch to a more modern authentication stack than PAM > should we ever get one. > > I agree it would be a lot of work to reimplement this just to get rid of > the libpolkit-agent-1.so dependency. Then again, I don't see why it > would be a problem to use this code in KDE since a) your authentication > agent would be a separate application; and b) all the deps are on the > disk anyway since they are also used in the PolicyKit daemon proper > (except for PAM but that is very likely to be on the disk). I am just looking for a confirmation that this library is here to stay. We're about to face a rewrite because of polkit-dbus and polkit-grant being deprecated, and I really want to avoid such a thing again if not in some years. If you tell me I can count on polkit-agent, then there is not a problem in using it in KDE. > > > > Great to hear that you're aiming for binary compatibility. > > I should clarify here. I don't plan to break the libpolkit-agent-1.so > interface once 1.0 is out, not without an so-name-bump anyway. Ok, that at least is good > > But we might want to break it if something better than PAM comes along. > But since libpolkit-agent-1.so is a small library, it shouldn't be very > painful and so-name-transitions is a pretty well-understood thing > anyway. My 2 cents: why not switching to a backend system? It would definitely make the transition easier, should the case happen, and will save you a lot of possible future work and binary compatibility of polkit-agent. I volunteer for helping you: if you're interested in such a thing, this is definitely the right time. > > So the authentication is completely abstracted in the mechanism and > > everything happens in it? That sounds really like good stuff :) > > Right, this is how PolicyKit 0.9.x works > > http://hal.freedesktop.org/docs/PolicyKit/diagram-interaction.png > > e.g. the desktop app needs to poke the authentication agent itself. > Works great but means there's a lot of work needed in each app. > > Parden my ASCII art (I need to write proper docs for polkit 1.0, so this > will have to do for now), this is how PolicyKit 1.0 works (where p-a-h-1 > is the setuid root authentication helper used by libpolkit-grant-1.so): > > +--------------+ +----------------------+ +---------+ > > | File Manager | | Authentication Agent | <--> | p-a-h-1 |--\ > > +--------------+ +----------------------+ +---------+ | > ^ | ^ | PAM | | > > | | | +---------+ | > > 6.OK | | | | > > | | 1. Mount() | 3. BeginAuthentication() | > | > | V | | > > +-----------------+ 2. CheckAuthz() +-------------------+ | > > | |---------------->| | | > | > | org.fd.DK.Disks | | org.fd.PolicyKit1 | | > | > | |<----------------| | | > > +-----------------+ 5. Authorized +-------------------+ | > ^ / > \------------------------ > 4. AuthenticationAgentResponse() > Nice picture, definitely :) > > One main difference here is that call number 1., Mount(), might block a > long time while the authentication is happening. So apps like a file > manager need to cope with that. But file managers already needs to cope > with stuff like that since it's an IPC call. > > But, anyway, as you can see the file manager (e.g. Nautilus or Dolphin) > won't have to know anything about PolicyKit at all. Same goes for every > other user of PolicyKit.... just simpler all around. Ok, then I definitely understood you well in the last mail, and I can just repeat that this change is much appreciated :) > > Hope this clarifies. > > David -- ------------------- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/polkit-devel
