Integrate high privileges in KIO and GHNS

[Nicola Gigante]

Il giorno 21/ago/09, alle ore 12:55, David Faure ha scritto:

> Sounds great. A very much needed feature.
>
Thank you :D

> I see several approaches, but since I don't know kauth, no idea  
> which is
> better... Let me do a bit of brainstorming:
>
> Is there some caching of passwords?
> If yes: then we can indeed "ask for permission" at the lowlevel (kio  
> file-copy
> job, or inside the kioslave itself) and other files to be copied  
> (e.g. as part
> of a higher-level directory CopyJob) will be copied using the cached  
> password.
>
KAuth it's not a matter of "passwords". It works with policies, just  
like PolicyKit (which is its linux backend). That means the  
authentication is handled and credientials are granted by "someone  
else", which on linux is policykit. Currently, policykit and the mac  
backend handle the authentication asking passwords, but it's only an  
implementation detail that we don't have to care.

> In fact, do we have to use a password dialog from kauth, or could the
> kioslaves request for auth just like they do already when going to  
> an ftp or
> http site that needs a password, and then give that password to kauth?
>
The password (if needed) is asked by the policykit authentication  
agent, which is a separate process. The app using libkauth doesn't  
have access to the password or to any authentication detail. It simply  
knows that it can or can't do what it asked.

> So, one idea is that the slave could detect the problem, ask for
> authentication (via the main process, of course, we don't want GUIs in
> slaves), and proceed;
> we would have the issue of sharing that information with other  
> kioslaves
> involved in the same operation (e.g. recursive directory listing),  
> though
> (I guess we don't want to just cache the password in kpasswdserver  
> like we do
> for FTP/HTTP, that would allow -other- operations to have root  
> access).
>
> A different approach would be that libkio reacts on the error codes  
> that
> indicate a lack of permission, call kauth, and "try again"? There  
> are quite a
> few jobs that would need touching, but that's less duplication/work  
> than the
> solution below.
>
I think the second approach is the better, for two reasons:
1) We don't have control over credential caching. We can provide an  
hint to tell that credentials should be cached, but the backend can  
ignore it, for example if the system admin has changed that setting.  
Even if the admin doesn't touch the configs, the policykit  
authorization dialog will ask the user if it wants to save the  
credentials or not. This means we have to reduce the number of  
authorization requests needed to perform an operation, because every  
authorization request could result in a password dialog, if the user  
chose to not save the credentials. I think doing the auth request at  
an high-level allows us to do that.

2) If we implement support in every single slave, the code duplication  
is _really_ a _lot_. Remember we have to write an helper tool that  
actually perform the action. With the first approach we have to  
duplicate a lot of slave's code into the helper, for every slave that  
we want to support. With the second approach, we only have to write an  
helper that relaunch the job: a lot less work.

> Finally another approach would be that the application's slotResult  
> detects
> the error and retries the _whole_ job after authentication. But that  
> limits
> the feature to file managers (and GHNS), so I guess we don't want  
> that, if we
> want "save file" in any application, to be able to save in /etc for  
> instance.
>
yeah I think this is what we want: developer-transparent support for  
this feature, so I think we've to exclude this approach.

> All of this depends on whether kauth can give other processes  
> (kioslaves)
> permissions, or if it's all in-process.
Yes it can. Actually, it doesn't matter which process requests the  
action authorization and which process actually perform the action.


bye bye,

Nicola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090821/c1be4da0/attachment.htm>