From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 17:07:14 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53C4D1065758 for ; Tue, 14 Apr 2009 17:07:14 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 04E2A8FC21 for ; Tue, 14 Apr 2009 17:07:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1572264yxm.13 for ; Tue, 14 Apr 2009 10:07:13 -0700 (PDT) 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= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=anAvSJ4Rqu9GrOdkZCQltN3h0jWQejCEW0qURe2ciPMBqE26GdGclAYcmmeESnlhI4 mWcG2FkjjpbpyodxPeg58w/XGx4DbIb97JRT8YsZQ6MKxMZTYRKiiaz9R0mNRQ/wuCZS in65ssxUHwX3TFNFBsegjEQgawqKqO4N5tyZo= MIME-Version: 1.0 Received: by 10.90.105.17 with SMTP id d17mr10033325agc.92.1239728833310; Tue, 14 Apr 2009 10:07:13 -0700 (PDT) In-Reply-To: <1239725723.321671.1132.nullmailer@galant.ukfsn.org> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <1239725723.321671.1132.nullmailer@galant.ukfsn.org> Date: Tue, 14 Apr 2009 10:07:12 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "Mikhail T." Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:07:15 -0000 On Tue, Apr 14, 2009 at 9:15 AM, Iain Hibbert 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 > >