Re: [Tracker] Running Tracker with dbus system bus

[Martyn Russell <martyn lanedo com>]

On 02/01/14 10:36, Ralph Böhme wrote:
> Philip
>
> thanks for your thoughts, highly appreciated!

Hi all,

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

You're not the first to ask for this. We've been asked about having
something like this for shared resources like man pages or help in the
past too. It's just never been of huge interest to everyone and so has
never been implemented.

Shared resources also present other problems - the main one I can think
of, is joining results from two different tracker databases. This has
performance and security implications and we've entirely avoided it so far.

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

I think a proper system level design is a good idea at some point.
I think if you want indexing of system resources, you should really go
down the path of either cgroups or a defined system user/group for
system resources to be indexed in. I think the complication is mostly
around indexing, not around querying the data, at least initially while
you do it separately of your own private data.

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

True, mmap is used for performance reasons as I recall.

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

I really wouldn't use root though. I would simply have a lesser
user/group specifically set up and designed for this, like 'lp', 'sshd'
etc do. That way you can clearly separate the process abilities from the
power of root.

The requirements of tracker really aren't that complex. There might be
some system APIs we use which are restricted in places (hence why an
audit would make sense), but generally, we would need read privileges
for system files and write privileges for the database, config and
caching (which is already handled on a user basis - i.e. ~/.something).

It then gets tricky when you want other users accessing this data. Over
DBus it's not so bad, but directly opening the files as we do for read
only access wouldn't work this way. Instead you would want to use
something more public, like /var or /usr/share? Not sure about the rules
for using either of these locations is, i.e apt uses /var, desktop
application caches are in /usr/share.

I have not thought this through at all BTW just brain dumping here :)

It might make sense to look at other system level services that provide
access to data or caches and see what policies they use and choose
something similar according to our requirements.

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

Or environment variable - I like my environment variables :)

> fwiw, the requirements for the described use case don't neccessarily
> require running Tracker as root. What's need is using dbus system
> context, not session context, so that arbitrary users (processes with
> distinct uids) can connect. The latter is not allowed by dbus for

I've actually been wondering this since the start of this thread. Is 
there some reason why using the SYSTEM bus for all communication instead 
of the SESSION bus can't be done? It wouldn't take much to patch and 
should work. It doesn't solve the problem for direct-access clients 
though and that's generally faster when querying.

> user context services (ie you can't connect as arbitrary user to a
> dbus session service from another user (another euid that is)).
>
> A proper solution (with security in mind) might be * add an option
> that makes Tracker use system dbus context instead of session
> context * add another option to take a user under which Tracker will
> run in this case, this user MUST not be root

In the short term, we might be able to fix this without even thinking 
about the user running the processes (root or whoever), but rather just 
use the right dbus context. Then it's up to distros or whoever uses 
Tracker to run it under a separate user for the SYSTEM bus.

I don't think this should be a build-time option, but rather a run-time 
option. It's likely you want to run Tracker more than once on the same 
system with shared and non-shared resources.

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell