Re: RFC: obexapp - virtual root folder for each device

[Maksim Yevmenkin <maksim_(_dot_)_yevmenkin_(_at_)_gmail_(_dot_)_com>]

On Tue, Apr 14, 2009 at 9:15 AM, Iain Hibbert <plunky_(_at_)_rya-online_(_dot_)_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
>
>
_______________________________________________
freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"