Philip thanks for your thoughts, highly appreciated!
Am 02.01.2014 um 11:07 schrieb Philip Van Hoof <phi...@codeminded.be>: > Signierter PGP Teil > 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. Point taken. > 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). 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 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 Thanks again! -Ralph
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
