Return-Path: Subject: Re: [Bluez-devel] Using ASCII based files for link key storage From: Marcel Holtmann To: bluez-devel@lists.sourceforge.net In-Reply-To: <200504162321.54562.bluez-devel@schaettgen.de> References: <1113668583.16433.76.camel@pegasus> <200504161932.39416.bluez-devel@schaettgen.de> <1113678271.16433.85.camel@pegasus> <200504162321.54562.bluez-devel@schaettgen.de> Content-Type: text/plain Message-Id: <1113687490.18450.15.camel@pegasus> Mime-Version: 1.0 Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 16 Apr 2005 23:38:10 +0200 Hi Fred, > > > > And second, The format of the link key file will be very simple: > > > > > > > >

> > > > > > This means that we will still be unable to list the devices for which a > > > link key exists without root privileges, is this correct? If yes, is this > > > intentional? > > > > there is no other way, because we must store the link keys as secure as > > possible. > > Sure, but my question wasn't about the link keys themselves. Why not allow > regular users to find out if there is a link key for a given device at all, > without being able to see the link key itself? I don't know if knowing about > the existance of a link key might be sensitive information, too. But at the > moment I don't see any problem with it. Bluez could create one file per > device for instance, with the bdaddr as its name and the rest in it contents. > > This would still leave the type and time .. oh.. it's gone.. ok, it would > leave only the type unreadable for unprivileged users. But everybody could > take a look into the /var/lib/bluetooth// dir to find out if > bluez might be paired with a given device or not. > But again, I don't really need this feature. I'm just throwing some thoughts > in the ring. I don't like the idea of creating so much files. One file for each link key doesn't looks reasonable to me. However in the long term I plan to merge hcid and sdpd and create a nice Unix socket based API for tasks like managing link keys etc. And then I can enforce different privileges. > > > Anyway, I for myself don't care much about where the data goes, as long > > > as the location and the file formats stay stable, because the link key > > > manager of kdebluetooth has to be changed each time. > > > > In the long term I like to make the place totally configurable, but for > > now I think going with /var/lib/bluetooth and ASCII based files is a > > good think. > > Make the paths configurable? In hcid.conf? Why would someone want *that*? > Isn't it a good thing that we can depend on the bluez files staying at a well > known place? If a weird distribution chooses to place the files in a > completely different directory, then some build time options should be > sufficient for them. Ah, ok, maybe that's just what you meant. This is not for the desktop world. It is for people that are using BlueZ in embedded devices. They will need things like this. Regards Marcel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel