[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Integrate high privileges in KIO and GHNS
From:       Nicola Gigante <nicola.gigante () gmail ! com>
Date:       2009-08-21 11:23:48
Message-ID: 7BEDA31F-7419-48E8-B170-132B7AC4F5BD () gmail ! com
[Download RAW message or body]

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
[Attachment #3 (text/html)]

<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>



[prev in list] [next in list] [prev in thread] [next in thread]