|
Bugzilla – Full Text Bug Listing |
| Summary: | /etc/bluetooth/link_key not written | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | ferdinand gassauer <gassauer> |
| Component: | Network | Assignee: | Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | behlert, security-team |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
ferdinand gassauer
2006-02-14 13:38:38 UTC
Sorry but please be more specific. Which application are you talking about? bluetooth pairing (blueZ, multisync, kdebluetooth) This is a different issue. - /etc/bluetooth/link_keys is bogus. we need linkkeys for every BT adapter, not just one - bluez stores the linkkeys in /var/lib/bluetooth/<MAC>/linkkeys, <MAC> is the address of the BT adapter - in 10.0 there was a bug which caused the linkkeys to be written to /usr/var/lib/bluetooth..., but other applications wanted them in /var/lib/bluetooth..., this is bug 127781. I think this is a duplicate of 127781. thanks - saved my life ;.) work around: create a link in /var/lib/bluetooth # ln -s /usr/var/lib/bluetooth/<mac addr> <mac addr> then everything works again. IMHO for security reasons the pairing info should reside in ~/.bluetooth/<mac addr>/linkkeys because I do not understand, why another user should have access to "my" paired devices. Or do I see it wrong? (In reply to comment #4) > work around: > create a link in > /var/lib/bluetooth # ln -s /usr/var/lib/bluetooth/<mac addr> <mac addr> Yes, this might work around the bug. If everything is working fine with this, we might consider putting out a howto for 10.0 to fix this. I have to reproduce this on 10.0 myself and think about it; the we will decide if an update or a howto is the best solution ;-) (In reply to comment #5) > IMHO for security reasons the pairing info should reside > in ~/.bluetooth/<mac addr>/linkkeys > because I do not understand, why another user should have access to "my" > paired devices. IMO this is not so black-and-white: - IIUC you have to be root to pair the devices anyway (done by hcid) - i want to use my dialup connection directly after boot, even before a user is logged in ;-) This is something to consider for sure, but you probably better take this to the upstream bluetooth-maintainers. > > Or do I see it wrong? > IMHO the pairing is down and written by root, but initialized from ONE user. So from the users point of view it's done by the user. if the dial up connection should be available commonly before user login, this could be a (revokable) option, but not a silent "feature". sorry I ment "pairing is DONE" I have crossposted this bug to bluez-devel@lists.sourceforge.net IMHO the security question is (also) device dependant. a bluetooth printer might be available after booting, a mobile phone not or only partially (making fax / phone calls, but NOT addressbook and calendar, pictures etc) up to comment #4: this is working fine in 10.1, i will probably have a hard time putting out a bluetooth update for this issue and 10.0 now. comments #5 up: this is being worked on upstream with the bluetooth-dbus API IIUC. So i'll close this as fixed, although it really is only fixed in 10.1 :-( |