Hi, On Fri, Jan 14, 2011 at 17:52, Patrick Ohly <[email protected]> wrote: > Hello Buteo team! > > I'm happy to report that Paul's gadgetfs-based transport for the Media > Transfer Protocol (MTP) passes initial tests and that we obtained > permission to publish the code. We'll do so shortly and hope to get this > included in buteo-mtp. Great!
> Currently the code runs as part of mtp_test when started as root. That's > necessary because /dev/gadget must be read/writable. But eventually the > code needs to run as plugin as normal user inside msycnd. Initially the > process accesses /dev/gadget/<driver> to configure USB, then some new > entries (like /dev/gadget/ep-a) which are created by gadgetfs based on > that configuration. We could do a "chmod" as root to grant the msyncd > process read/write permission for /dev/gadget/<driver>, but that doesn't > help with the additional files, which are exclusively for root. If > anyone knows how to solve this, ideally without patching the kernel, > please speak up... As these are devices, they would appear through udev events so you can handle it with udev scripts. > Even if there is a solution, which permissions would be suitable? We > don't want to grant all user-space processes the right to modify the > device's USB config. Here's one possibility: > * add a group "sync" > * make msyncd setgid "sync" > * grant the "sync" group read/write access > > The drawback is that everything running inside msyncd, including > third-party plugins, will have the possibility to reconfigure USB. I > don't see how this can be avoided, except by separating different sync > sessions into different processes. Splitting out the setup phase into a > separate setuid or setgid binary does not work, because the MTP > transport in msyncd needs full read/write access to everything, > including the main /dev/gadget/<driver> file descriptor. > > IMHO granting privileges as part of the MeeGo Security Framework has > similar issues and perhaps changing msyncd such that it runs each sync > inside a separate process would be worthwhile in the long run (also > better for stability), but this is clearly out of scope right now. Yes, this is drawback clearly and process separation is welcomed. We did same in sharing framework when webupload-engine needed to load plugins which would do access to accounts and sign-on storage. So plugins are run in separate processes now. > /usr/share/mtp/deviceinfo.xml contains information like hardware vendor > and model. We need a way how this can be modified without recompiling > buteo-mtp. Perhaps the file could be installed in and read > from /etc/mtp, where device images or scripts can modify it? I think we need to follow traditional FHS way of handling config files (after all, this is config file) and have the default in /usr/share/mtp but use it only if /etc/mtp does not contain the one. > The path under which files are made accessible via MTP is currently > hard-coded to /home/user/MyDocs. "PlayLists" as sub-directory of that is > created by the MTP code. > > What is the purpose of "PlayLists", or in other words, how is it > special? How can the /home/user/MyDocs path be made configurable? Would > deviceinfo.xml be a good place? Could we use XDG user-dirs instead? Qt gives you QDesktopServices::storageLocation() for most of those paths albeight this is part of QtGui code even though it could have been in QtCore (there is only string management there and some cludge for openDocument() method around X11). So MyDocs would be QDesktopServices::storageLocation(QDesktopServices::DocumentsLocation). Alternatively, you can take inspiration from storageLocation() and make own implementation which does not require QtGui (it doesn't for this particular part, just placement of the method is a bit unfortunate). -- / Alexander Bokovoy _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
