
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Il giorno 21/ago/09, alle ore 12:55, David Faure ha scritto:</div><br><blockquote type="cite"><div>Sounds great. A very much needed feature.<br><br></div></blockquote><div>Thank you :D</div><br><blockquote type="cite"><div>I see several approaches, but since I don't know kauth, no idea which is <br>better... Let me do a bit of brainstorming:<br><br>Is there some caching of passwords?<br>If yes: then we can indeed "ask for permission" at the lowlevel (kio file-copy <br>job, or inside the kioslave itself) and other files to be copied (e.g. as part <br>of a higher-level directory CopyJob) will be copied using the cached password.<br><br></div></blockquote><div>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.</div><br><blockquote type="cite"><div>In fact, do we have to use a password dialog from kauth, or could the <br>kioslaves request for auth just like they do already when going to an ftp or <br>http site that needs a password, and then give that password to kauth?<br><br></div></blockquote><div>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.</div><br><blockquote type="cite"><div>So, one idea is that the slave could detect the problem, ask for <br>authentication (via the main process, of course, we don't want GUIs in <br>slaves), and proceed;<br>we would have the issue of sharing that information with other kioslaves <br>involved in the same operation (e.g. recursive directory listing), though<br>(I guess we don't want to just cache the password in kpasswdserver like we do <br>for FTP/HTTP, that would allow -other- operations to have root access).<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><blockquote type="cite"><div>A different approach would be that libkio reacts on the error codes that <br>indicate a lack of permission, call kauth, and "try again"? There are quite a <br>few jobs that would need touching, but that's less duplication/work than the <br>solution below.<br><br></div></blockquote><div>I think the second approach is the better, for two reasons:</div><div>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.</div><div><br></div><div>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.</div><br><blockquote type="cite"><div>Finally another approach would be that the application's slotResult detects <br>the error and retries the _whole_ job after authentication. But that limits <br>the feature to file managers (and GHNS), so I guess we don't want that, if we <br>want "save file" in any application, to be able to save in /etc for instance.<br><br></div></blockquote><div>yeah I think this is what we want: developer-transparent support for this feature, so I think we've to exclude this approach.</div><br><blockquote type="cite"><div>All of this depends on whether kauth can give other processes (kioslaves)<br>permissions, or if it's all in-process.<br></div></blockquote><div>Yes it can. Actually, it doesn't matter which process requests the action authorization and which process actually perform the action.</div></div><br><div><br></div><div>bye bye,</div><div><br></div><div>Nicola</div></body></html>