Date: Tue, 14 Apr 2009 10:07:12 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Iain Hibbert <plunky@rya-online.net> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, "Mikhail T." <mi+thun@aldan.algebra.com> Subject: Re: RFC: obexapp - virtual root folder for each device Message-ID: <bb4a86c70904141007l48b347f9qab966cc12cc7be34@mail.gmail.com> In-Reply-To: <1239725723.321671.1132.nullmailer@galant.ukfsn.org> References: <bb4a86c70904131640n7cf471c0o7a56a43d722a90e1@mail.gmail.com> <49E3DB35.4030601@aldan.algebra.com> <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com> <49E41DBB.5090805@aldan.algebra.com> <1239725723.321671.1132.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 14, 2009 at 9:15 AM, Iain Hibbert <plunky@rya-online.net> wrote: > 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. its only to call accept() and fork(). child process drops privileges right after that. in fact, i believe, there is no network i/o performed while child is running with elevated privileges. so, the window is small here. >> 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 :) as i suggested, in private email, something like apache's .htaccess mechanism would be an ultimate solution here. however, its way too much complicated for what obexapp is :-) > 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. that's, actually, an interesting idea. i could see how it could be applied to almost any bluetooth service. its not that much work, imo. obexapp already can use stdin/out as file descriptors (in client mode). configuration aspect of it is a pain though. perhaps we should think along the lines of bluetooth inetd that maps pair (protocol, protocol parameters) to service? something like (l2cap, 1) -> sdpd, (rfcomm, 1) -> obexapp, (rfcomm, 3) -> rfcomm_pppd etc.? >> 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) yes, that is what i was thinking too. its pretty much like running multiple copies of obexapp without actually running multiple copies of obexapp :) thanks, max > > regards, > iain > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70904141007l48b347f9qab966cc12cc7be34>