Date: Tue, 14 Apr 2009 17:15:23 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: "Mikhail T\." <mi+thun@aldan.algebra.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: RFC: obexapp - virtual root folder for each device Message-ID: <1239725723.321671.1132.nullmailer@galant.ukfsn.org> In-Reply-To: <49E41DBB.5090805@aldan.algebra.com> References: <bb4a86c70904131640n7cf471c0o7a56a43d722a90e1@mail.gmail.com> <49E3DB35.4030601@aldan.algebra.com> <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com> <49E41DBB.5090805@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Apr 2009, Mikhail T. wrote: > > i beg to differ. main process (the one that accepts connection) is > > running with elevated privileges, yes. > >From the security standpoint, this negates all/most benefits of having a > dedicated UID for the service. The security people will tell you, that, I agree too, its not good to run a daemon (that can be accessed over a radio link and create/modify files no less) as root. > I agree, that continuing to run as root after accepting connection is > bad -- if a matching entry is not found, the server, indeed, ought to > setuid to some non-root user (as set by the -u switch or determined from > the ownership of the top-level itself). However, the above-mentioned > cooperation may still have its uses for some people. That said, they can > have all their BD_ADDR symlinks point to the same directory and > cooperate there, so I don't feel strongly about it either. If you did that, it would I think be better to have the bdaddr mapping in a config file. Symlinks are too much trouble. On the other hand, I'm not keen on config files either :) Also, it could be better in that case to have a master daemon (along the lines of inetd) that could accept connectins and start obex according to the remote device address. Thats perhaps a lot of work though. > > i also must say that we are trying to solve the problem at the wrong > > level. more specifically, for phone book back up you probably want to > > use something else (like sync-ml for example) not not obexapp. > > > Not sure, what "sync-ml" is (there is no such port). Try "msynctool" which uses libopensync, it has a pluggable API for different sync protocols (syncml is Nokia, synce is Windows) and is run from the computer end so you wouldn't have any issues with incoming files. > But what about dropping camera's pictures and videos? People would > certainly expect to be able to do that straight from their devices > (rather than by running a client of some sort), and find the files > somewhere under their home directories (perhaps in ~/Desktop). Do you want to send pictures to your account when your wife is logged in, or does she want to when you are logged in? I don't know what prior art is there, but it seems to me that (as I said before) the person logged in at the console owns the machine and should receive files being sent. As Max said, Bluetooth is not big on credentials, it is assumed that all users (normally a only one) have equal access. For this reason, Bluetooth cannot properly be a multi-user link unless all the users trust each other (while Alice is sending files to the computer, Bill could be checking her phone log) so I don't see a problem with having all the files in a master directory owned by the same user (but setting the default path per remote device seems a good compromise) regards, iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1239725723.321671.1132.nullmailer>