Re: [Tracker] Running Tracker with dbus system bus

[Philip Van Hoof <philip codeminded be>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralph Böhme schreef op 2/01/2014 10:36:

Hi Ralph,

> > I think your seteuid() to drop to the user-ID from root should
> > be called from your code rather than in libtracker-sparql.
>
> I think you misunderstood what I was trying to describe. I
> seteiud() to root in the application before calling tracker-sparql
> stuff, because I'm launching a private dbus in the root user
> context which is then starting Tracker daemons in root user
> context.

Aha yes I misunderstood that. I thought you were running Tracker as a
user and wanted to query it from root.


> <https://github.com/Netatalk/Netatalk/blob/develop/etc/spotlight/slmod_sparql.c#L74>
>
>  The application process normally runs uid=0,euid=some-uid. In
> order to be able to talk to Tracker via dbus, which are both
> running in root user context, I seteuid(0) and back when using
> tracker-sparql stuff.
>
> I must run Tracker as root, because I must be able to index a
> _shared_ ressource, ie all files of a fileserver (currently
> AFP/Netatalk, in the future SMB/Samba).

Ok, makes sense.

However, and especially given recent revelations in the news of
governments being interested in hacking into our devices (however
crazy that in itself is); tracker-extract links with a huge amount of
externally maintained code and given that this code operates with user
defined input (the files on a filesystem); I would advise very
strongly against running tracker-extract as root. Even our own code
isn't coded with high security standards in mind, although we always
and still do tag such bugs with highest critical priority.

I think it's comparable to the sore situation of extensions and GLX in
X.Org. I also think we'd need the focus of a community of a few
hundred people to make all that code secure. It is that serious and
I'd like to make sure that everybody who runs tracker-extract as root
is aware of this and wakes up in the middle of the night soaked in
cold sweat, every night, for at least half a year for each user that
he burdened with that risk.

What I would propose is to investigate the use of Linux lightweight
containers to let the tracker-extract process run in, or using
set(e)uid to drop privileges of tracker-extract as soon as possible
(for example after getting the open fd, drop privleges, and continue
with read. But I'm not even sure whether that will work - so
experimenting and investigating on this should probably be done).

For example no extractors need write access to files, so the container
and/or user to drop privileges to wouldn't need it, the mp3 extractor
needs mmap, God knows what the GStreamer based ones need, etc.

I don't think running tracker-miner-fs' process as root is as much of
a risk (as tracker-extract), although a security audit would need to
be done. Same for tracker-store.

> Trackers is apperently designed for a single user context, not for
> use a general purpose indexer on a server that shares ressources
> with clients by means of filehsharing protocols like SMB, AFP or
> NFS.
>
> > Is there a reason why libtracker-sparql must be adapted?
>
> The whole Tracker design must be updated to optionally allow
> running Tracker in dbus system context, not in user context.

Yes I agree with this for your use-case.

I think it should be at least a option, a commandline switch or
perhaps even a compile time option. I wouldn't be against it (noting
to your users the warning about tracker-extract that I just gave -
which I do think you ought to take very serious).

Philip

>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxTp5AAoJEEP2NSGEz4aDEwYH/jPSgeWnu76Wwew6qb610WVi
yVwb/hS/EQ7C9lt/3JcqeKEpAInayAiBDxGVqYSZ7KTHl1wwRGDgaa3KR1Z8OKXL
Mgv4e360ieFmy9ldyw37PWrVWJmwtdyDlzTjy7XIdXIYbjAfRICAs3h7tDJc7X1x
UhexiaVuG8ZBLVr2mIKq3Mj0Xyf7us6FnncMA/p3KsoW9V/+hz6Rm3mGnJYHLrzV
i5nNvGNNnr7mlbdlnF9FxlpyeqLfQxWBVUqkpcB9AxcTcj7sJXjY2jw8R70Y7iBy
3aGzaHIFU3TU29AslTQl9CZ7+pHTqASx4Op9O+rwyPMmlE1o7vXbCnoSpGRj7jc=
=HHvu
-----END PGP SIGNATURE-----