Hi Philip Am 02.01.2014 um 10:20 schrieb Philip Van Hoof <philip codeminded be>:
Signierter PGP Teil Ralph Böhme schreef op 2/01/2014 9:49:Hi fishing for responses, so here it goes again... :) Am 16.12.2013 um 18:36 schrieb Ralph Böhme <rb netafp com>:I'm looking into integrating Apple Spotlight support for Mac OS X clients to Samba. In order to simplify the design I had chosen for Netatalk (launch my own dbus daemon in _root_ user context, seteuid(0) in user context AFP fileserver processes before every libtracker-sparql function call) I wanted the check back with you guys whether a patch for Tracker that would a (run-time) option to run Tracker in the system dbus context would be acceptable for you. I haven't looked at the relevant code yet, but I suppose this may actually be only a few lines of new code for the option and a few changes where we open the dbus bus via dbus-glib (afair) API.Via Vala's D-Bus support we use GLib's GDBus (on both sides). For read queries depending on access level to meta.db we use SQLite WAL journal for a direct connection with the meta.db. Relevant files: https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql-backend/tracker-backend.vala https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql https://git.gnome.org/browse/tracker/tree/src/libtracker-bus/tracker-bus-fd-cursor.vala https://git.gnome.org/browse/tracker/tree/src/libtracker-bus/tracker-bus.vala https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-dbus.vala https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-steroids.vala https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala
Thanks for the pointers.
I was just trying to ask, supposed I submit proper patches that would allow changing the default behaviour as described, would these patches be acceptible? There's no sense in maintaining this stuff downstream, because of the need to enable any downstream consumer who wants to marry Samba with Tracker (distros, OEMs) to do so using the default packages.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. <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). 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. -Ralph
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail