From owner-freebsd-bluetooth@FreeBSD.ORG Wed Mar 8 01:23:03 2006 Return-Path: X-Original-To: freebsd-bluetooth@FreeBSD.org Delivered-To: freebsd-bluetooth@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 232CD16A420 for ; Wed, 8 Mar 2006 01:23:03 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B649943D49 for ; Wed, 8 Mar 2006 01:23:02 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id k281MoM01919; Tue, 7 Mar 2006 20:22:52 -0500 Message-ID: <440E31E7.9050409@savvis.net> Date: Tue, 07 Mar 2006 17:22:47 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iain Hibbert References: <440DCFF0.6090809@savvis.net> <1141761895.037384.5308.nullmailer@galant.ukfsn.org> <440DF38F.7020707@savvis.net> <1141772196.551930.3681.nullmailer@galant.ukfsn.org> <440E1988.10202@savvis.net> <1141779342.768110.17808.nullmailer@galant.ukfsn.org> In-Reply-To: <1141779342.768110.17808.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: apple bluetooth keyboard 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: Wed, 08 Mar 2006 01:23:03 -0000 Iain Hibbert wrote: > On Tue, 7 Mar 2006, Maksim Yevmenkin wrote: > >>well, this is the completely different can of worms. both hcid (in linux) and >>hcsecd(8) (in freebsd), to some extend, assume that there is only one user. >> >>bluepin is just x11 application. it will display windows on whatever DISPLAY >>is set at the moment. > > yes, but hcsecd cannot start it, because hcsecd is a different uid and has > no permissions to access the display.. besides, it is not the function of > a daemon to put windows on the display. Displays belong to users, if there > are any. If they want windows to open, they will run programs that do > that. well, fine. in this case bluepin must register with hcsecd(8) to get notifications for the pin code requests. i have no problem with it. >>>If user 'blue' wants to enable pin code requests, he can run the pin >>>program (maybe from .login) and it would open the control socket (which >>>can have ownership and permissions specified?) and sleep, listening for >>>pin requests, and wake up with a window when something happens. >>> >>>If user 'red' does not care about bluetooth, she just does nothing and >>>will never be bothered. > >>may be. but what if user 'red' also wants to run pin program. now hcsecd(8) >>will have two control pipes. which pipe should it use? should it use both? are >>you suggesting that hcsecd(8) should be configured to redirect pin requests >>from specific devices to specific pipe? > > that could be problematic - can a unix domain socket be opened by multiple > users for read/write? sure, why not. > In fact, multiple simultaneous users gets ugly, as sockets in general do > not have access permissions in any case - if user 'blue' opens the you can pass credentials via unix sockets > baseband connection, then 'red' can access the device through another > L2CAP or RFCOMM socket (well, they can in my world :) you can do it with freebsd. i can open baseband by hand (as root) and then do sdp query and/or rfcomm session as another user. i'm not following you here. >>btw, what usage scenario do you have in mind that requires multiple users to >>access the same (or multiple) bluetooth devices on the same host? > > my thought was that users might be consecutive ?? please explain >>so, i think, the something like bluepin will work just fine. the only issue >>here is that user required to run gui. > > well, if you are trying to set up a pairing to another device from a > computer with only a text console, you can always add the pin code to the > config file directly? yes, you can. but its painful. > then hcsecd could use LOG_NOTICE instead of LOG_DEBUG at this point. yes, and again user has to watch the logs for the messages. > alternatively, a helper application could be run in advance, if hcsecd > would remember a given pin/device combo for N seconds > > % tiepin -a phone 1234 > % rfcomm_sppd -a phone > may be. thanks, max