[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: obexapp - virtual root folder for each device
- To: Iain Hibbert <plunky_(_at_)_rya-online_(_dot_)_net>
- Subject: Re: RFC: obexapp - virtual root folder for each device
- From: Maksim Yevmenkin <maksim_(_dot_)_yevmenkin_(_at_)_gmail_(_dot_)_com>
- Date: Tue, 14 Apr 2009 10:07:12 -0700
- Cc: "freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org" <freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org>, "Mikhail T." <mi+thun_(_at_)_aldan_(_dot_)_algebra_(_dot_)_com>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yOA6kEvQFv5hJuCmHVpSYFOzIBiKtx9zdEbsYmrdSAg=; b=ZNGeqKPwBO7cvQz4rT3L66OmJnvvOR/O+OFCbna/9/m/DggxcdLBtwxp3OTIcg6MIL DXkhOiH1LIeprPVF1LnNOf4EPT98HyfbqhfIS0fM2FI//kbRdLue3WhlTCn9oPFxpqiQ OKSIxJhopoT95A+7pzxE9Ww9qRKjW0DHQCD8Y=
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
freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"