<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Valentin,<br>
<br>
Am 03.10.2010 23:47, schrieb Valentin Rusu:
<blockquote cite="mid:201010032347.26157.kde@rusu.info" type="cite">
<meta name="qrichtext" content="1">
<style type="text/css">
p, li { white-space: pre-wrap; }
</style>
<p style="margin: 0px; text-indent: 0px;">Hello,</p>
<p style="margin: 0px; text-indent: 0px;">Since our last meeting,
last week, I figured out how to get the caller process PID using the
QT4 API, hinted on my way by Havoc Pennington.</p>
<p style="margin: 0px; text-indent: 0px;">Now, that I'm able to get
the caller PID, I'm now able to get the calling process information,
such as the cmdline and executable file.</p>
</blockquote>
<br>
Awesome!<br>
<br>
<blockquote cite="mid:201010032347.26157.kde@rusu.info" type="cite">
<p style="margin: 0px; text-indent: 0px;">Here is what I'm trying to
implement next :</p>
<p style="margin: 0px; text-indent: 0px;">- when a process opens a
session and create a collection, we'll store along in this collection
information about the calling process,</p>
<p style="margin: 0px; text-indent: 0px;">- when a process opens a
collection for reading, we can check that it's executable file (or
cmdline ?) is the same before allowing it,</p>
<p style="margin: 0px; text-indent: 0px;">- this behavior should be
adjusted by the means of o policy file ; the policy file should be
under the responsibility of the client application (e.g. Kontact
application should install it's policy file it it wants ACL handling).</p>
<p style="margin: 0px; text-indent: 0px;">What do you think about
this ? </p>
</blockquote>
<br>
I currently planned to store ACLs per-collection inside the collection
itself. This is necessary because otherwise an application could just
create a policy file or add itself to a config file (like with KWallet)
to gain access (also, multiple applications usually have access to the
same collection).<br>
<br>
Thus I'd propose the following:<br>
- When creating or unlocking a collection, the "credentials" (exe name)
is retrieved<br>
- it's checked against what the collection already knows and if the
application is not authorized we have a dialog popping up (I'd take
care of that and introduce it to the abstract UI so you can make use of
it). The dialog would be similar in functionality to the one from
KWallet. Alternatively the user could disable ACL checking altogether
(by a config value also stored inside the collection).<br>
<br>
I'm not yet sure what you mean with the policy file. Could you please
explain a bit more?<br>
<br>
<blockquote cite="mid:201010032347.26157.kde@rusu.info" type="cite">
<p style="margin: 0px; text-indent: 0px;">I also think the service
specification should be updated and agreed upon before going further
with the implementation. Where can I found the latest specification in
order to get it updated ? I currently know this location :</p>
<p style="margin: 0px; text-indent: 0px;"><a moz-do-not-send="true"
href="http://people.gnome.org/%7Estefw/secrets/html/index.html"><span
style="text-decoration: underline; color: rgb(0, 87, 174);">http://people.gnome.org/~stefw/secrets/html/index.html</span></a></p>
</blockquote>
<br>
Back then we decided that ACL handling will not be part of the spec
because every daemon should be free to choose whether to implement it
or not (ACL checking only partly secures the daemon right now, the
biggest attack vector is LD_PRELOADing an library that spies upon a
collection inside an authorized application). This also means that ACLs
have to be transparent to any client. As ACL handling might pop up a
dialog (as mentioned above), the operations requiring ACLs can only be
the ones which return Prompt objects (which is actually the only
restriction :-)).<br>
<br>
If you have further questions, you can also try to reach me on IRC
though frankly I'll almost be working 24/7 from Wednesday to Friday.<br>
<br>
Regards,<br>
Michael<br>
</body>
</html>