On Tue, 2011-03-08 at 08:43 -0800, Patrick Ohly wrote:
> On Di, 2011-03-08 at 10:31 +0000, Philip Van Hoof wrote:
> > Can somebody from Intel answer One of the questions about EDS?
>
> All you are asking for is performance. To me, that wasn't the main issue
> with Tracker. The key drawbacks of Tracker as storage for contacts are
> these:
> 1. only one address book
You can use either a graph or things like a nie:DataSource and the
property nie:dataSource to have multiple address books.
> 2. no support for controlling access
This is unfortunately as far as I know no different in EDS.
Tracker's plans for per-resource access control is to use its (limited)
support for graphs for that.
Access to metadata is then granted per graph. (not implemented, and I'm
not trying to make it sound that this is easy)
Combined with 1. that would mean that you could grant access to one
address book to application A, but not to application B, although B has
access to another address book.
So for example
INSERT { GRAPH <urn:protected-xxx> { <person> a nco:Contact ... } }
Application X would get access to urn:protected-xxx in some way. It does
a query for all nco:Contact, and it gets <person>.
Application Y would not get access to this. It does a query for all
nco:Contact, and it doesn't get <person>.
And explained lower: Application Y gets no read access to meta.db, so it
must use tracker-store who'd regulate this access. Nor can Application Y
use sqlite3_open on its own, as it has no read access other than via
tracker-store (which uses FD passing D-Bus as IPC).
> There are real-world scenarios (think mirroring sensitive enterprise or
> social web data) were an additional address book is needed, because data
> must not be mixed with the "normal" contacts.
Sure, ok
> You mentioned plans to add access control. Can that be implemented while
> retaining the direct read capability and the performance improvement
> that you mentioned when announcing that feature? Doesn't look possible
> to me.
I have to be careful now what I write because only after Aegis became
public were NDA things lifted a bit on this stuff ... (not our fault)
What I reply is available in gitorious publicly anyway, so hopefully
it's all fine ;-)
Check the files tracker.postinst and tracker.aegis, *.aegis:
http://meego.gitorious.org/tracker/tracker/trees/harmattan/debian
With Aegis we give certified applications read access to meta.db using
the <credential name="GID::metadata-users" />.
The directory $HOME/.cache/tracker is protected to be readable only by
processes in that got this GID granted through Aegis. The library
libtracker-sparql, which enables SPARQL query capability, detects
whether or not the process has access and selects either D-Bus (over fd
passing) or direct-access to meta.db based on the UNIX file permissions.
It is true that once a process has permission to read meta.db, that you
can't hide it the data that is in meta.db. We had no plans to do in-db
encryption as this would just make things horribly slow (decrypting
cells in custom SQLite functions, no thanks).
On Harmattan a plan was to only give certified applications the right to
add the GID::metadata-users credential. Meaning that the source code is
known to the vendor, and known not to abuse meta.db.
We investigated whether storing meta.db on a AegisFS was an option. But
because AegisFS uses FUSE, it is notoriously slow on each syscall.
Would meta.db be stored on a AegisFS, then the data would also be
protected using encryption (to survive reboot to root-mode).
> The other question of course is about the schedule. Access control is
> needed for products *now*, not in some distant future. EDS doesn't have
> access control either, but I consider it much easier to add (already
> based on a daemon concept, much more limited scope).
The same "daemon concept" applies to Tracker's tracker-store. As access
to meta.db is regulated through Aegis's GID:: credential.
Cheers,
Philip
--
Philip Van Hoof
freelance software developer
Codeminded BVBA - http://codeminded.be
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
