What stuff in gnome-bluetooth does, and ideas for its future
Edd,
tis 2003-11-04 klockan 01.47 skrev Edd Dumbill:
Quoted 3 lines
We need a way of finding out for which bdaddrs it has a key. Currently this information is stored in
/etc/bluetooth/link_keyand readable only by root, so we've some progress to make there.
I believe it would be helpful to change the link_key binary file format to ascii.
This would make the file more accessible and also simplify debugging, manual recovery, endianess compatibility, future data type compatibility and compiler issues such as the size of "time_t". Current format is:
struct link_key {
bdaddr_t sba;
bdaddr_t dba;
uint8_t key[16];
uint8_t type;
time_t time;
};An ascii version could be row based. What about like this?
00:11:22:33:44:55 66:77:88:99:00:11 6d450822cf944dcedd7a5b2e347e606f key_type 1075330902
Works with grep, awk, perl, emacs and so on too. :)
Fredrik
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
Hi
Quoted 3 lines
An ascii version could be row based. What about like this?
00:11:22:33:44:55 66:77:88:99:00:11
6d450822cf944dcedd7a5b2e347e606fkey_type1075330902
What about replacing /etc/bluetooth/link_key with an ASCII version in /etc/bluetooth/keytab? I'll work on a patch for it..
I'm also thinking about the possibility of making a device name cache in /etc/bluetooth/names, somewhat similar to /etc/hosts. And so whenever someone requests a scan this table can be updated:
# /etc/bluetooth/names # # Bluetooth address Last updated Device name 00:11:22:33:44:55 1075337039 Some Bluetooth device name 66:77:88:99:00:11 1075337039 Some other Bluetooth device name
The configuration for this service can for example be located in /etc/bluetooth/names.conf.
Having a device name cache makes it a lot easier to display the names associated with the addresses in the /etc/bluetooth/keytab file.
Comments?
Fredrik
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
Quoted 1 line · Fredrik Noring
Comments?
Well, these changes would definitely make me much happier. From a user interface level the user needs some visual feedback whether they're paired or not. Often "permission denied" means they've forgotten to pair, but we need to find a nice way to tell the user this when it happens.
-- Edd
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
On Thursday 29 January 2004 01:50, Fredrik Noring wrote:
...
Quoted 10 lines
I'm also thinking about the possibility of making a device name cache in
/etc/bluetooth/names, somewhat similar to/etc/hosts. And so whenever someone requests a scan this table can be updated:# /etc/bluetooth/names # # Bluetooth address Last updated Device name 00:11:22:33:44:55 1075337039 Some Bluetooth device name 66:77:88:99:00:11 1075337039 Some other Bluetooth device name
Quoted 7 lines
The configuration for this service can for example be located in
/etc/bluetooth/names.conf.Having a device name cache makes it a lot easier to display the names associated with the addresses in the
/etc/bluetooth/keytabfile.Comments?
A device name cache makes it not only easier to display names more quickly, but also can you use it the other way round to resolve device names. We use both for our sdp kioslave for KDE. The nice thing (for us) is that everything can be done as a regular user, so the daemon can be started along with KDE without suid'ing or similar.
Apart from the date of last name request, we also log when a device was last discovered and when we were last connected to it (even though this information is not used for anything yet ;)
I wasn't able to follow your whole discussion.. do you think this functionality should go into bluez itself or into gnome-bluetooth only? If it's the latter, it might be a good idea to use the same data store for both gnome and kde.. not sure if it's worth the effort, just a thought.
greetings
Fred
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
Marcel Holtmann
maintainerHi Edd,
Quoted 5 lines
Well, these changes would definitely make me much happier. From a user interface level the user needs some visual feedback whether they're paired or not. Often "permission denied" means they've forgotten to pair, but we need to find a nice way to tell the user this when it happens.
but you can't use the link key database for it. The link keys must be stored with the highest possible security and this means that they should only be readable and writable by root.
Regards
Marcel
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
Quoted 11 lines · Marcel Holtmann
Hi Edd,
Quoted 5 lines
Well, these changes would definitely make me much happier. From a user interface level the user needs some visual feedback whether they're paired or not. Often "permission denied" means they've forgotten to pair, but we need to find a nice way to tell the user this when it happens.
but you can't use the link key database for it. The link keys must be stored with the highest possible security and this means that they should only be readable and writable by root.
OK, I can see this. But it wouldn't be a violation if hcid maintained a file with a list of devices with which it was paired? That's really the information we're after. Well, that, and the ability to delete a link key.
-- Edd
Edd,
tor 2004-01-29 klockan 16.32 skrev Edd Dumbill:
Quoted 3 lines
OK, I can see this. But it wouldn't be a violation if hcid maintained a file with a list of devices with which it was paired? That's really the information we're after.
That's a good approach I think. We can have /etc/bluetooth/keytab and /etc/bluetooth/keytab.shadow (similar to /etc/passwd and /etc/shadow) where /etc/bluetooth/keytab is readable by all.
Quoted 1 line
Well, that, and the ability to delete a link key.
By invoking /sbin/hcid with a special unlink argument?
Fredrik
Hi Fred
tor 2004-01-29 klockan 12.30 skrev Fred Sch=E4ttgen:
Quoted 2 lines
I wasn't able to follow your whole discussion.. do you think this=20 functionality should go into bluez itself or into gnome-bluetooth only?=
=20
I think having Bluez managing this is a good idea, as it isn't a Gnome (or KDE) specific thing.
Any ideas on tools and interfaces? Btw., what's the character encoding for Bluetooth device names?
Fredrik
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
(..persistent device name cache..)
Quoted 6 lines
tor 2004-01-29 klockan 12.30 skrev Fred Sch=E4ttgen:
Quoted 2 lines
I wasn't able to follow your whole discussion.. do you think this functionality should go into bluez itself or into gnome-bluetooth only?
I think having Bluez managing this is a good idea, as it isn't a Gnome (or KDE) specific thing.
I also think that wouldn't be misplaced in bluez. But since it can be easil= y=20
done with a gnome/kde service, this proposal will surely go to the bottom=20 part of the wishlist if there is no demand from other unrelated projects.=20
Quoted 2 lines
Any ideas on tools and interfaces? Btw., what's the character encoding for Bluetooth device names?
UTF-8 and null-terminated as long as the name less than 248 bytes long.
greetings
=46red
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Edd and Marcel,
tor 2004-01-29 klockan 16.32 skrev Edd Dumbill:
Quoted 1 line
Well, that, and the ability to delete a link key.
Here's a nice solution I think:
Make hcid create a socket in /etc/bluetooth/keytab.socket. Preferably, having the same group membership as the socket (for examle "bluetooth") enables a user to send commands like:
DELETE <sba> <dba>
This makes hcid delete the link and update /etc/bluetooth/keytab and /etc/bluetooth/keytab.shadow accordingly. These are ASCII files of course and can also be maintained with Emacs or whatever tool although this is not as safe because of race conditions.
Then we'll extend hcitool with the ability to connect to this socket and do this stuff too.
The protocol can be extended in the future. Like for example initiating pairing procedures and so on.
What do you think?
Fredrik
tor 2004-01-29 klockan 21.19 skrev Fred Sch=E4ttgen:
Quoted 1 line
I also think that wouldn't be misplaced in bluez. But since it can be e=
asily=20
Quoted 1 line
done with a gnome/kde service, this proposal will surely go to the bott=
om=20
Quoted 1 line
part of the wishlist if there is no demand from other unrelated project=
s.=20
Here's a proposal:
Similar to the idea with /etc/bluetooth/keytab.socket, additional sockets can be created for other Bluetooth interface services such as name scans, lookups etc. Regular users have access to these capabilities based on socket file permissions.
Example:
/etc/bluetooth/names # The device name cache /etc/bluetooth/names.conf # The device name configuration file /etc/bluetooth/names.socket # The command socket
Command examples:
SCAN - Returns something similar to "hcitool scan"
LOOKUP <bdaddr> - Returns the name if available in the names file DELETE <bdaddr> - Removes the name from the names file
LIST - Lists all names in the names file
The hcitool utility can be extended with these features too.
Would this make it?
Fredrik
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
Marcel Holtmann
maintainerHi Fredrik,
Quoted 11 lines
Make hcid create a socket in
/etc/bluetooth/keytab.socket. Preferably, having the same group membership as the socket (for examle "bluetooth") enables a user to send commands like:DELETE <sba> <dba>
This makes hcid delete the link and update
/etc/bluetooth/keytaband/etc/bluetooth/keytab.shadowaccordingly. These are ASCII files of course and can also be maintained with Emacs or whatever tool although this is not as safe because of race conditions.
Quoted 5 lines
Then we'll extend hcitool with the ability to connect to this socket and do this stuff too.
The protocol can be extended in the future. Like for example initiating pairing procedures and so on.
I had some similar ideas some time ago and the idea of accessing the Bluetooth databases through a Unix socket with our own protocol is one of my favourites. This makes you independent from the database format (I prefer Berkeley DB at the moment) and you don't need to have database code in the Bluetooth library. But when we design it this way, we must make sure that we have the highest security for the link key transactions.
Additional commands can be NAME or ISPAIRED, but I am also not sure if a binary protocol would be better. Maybe we can use D-BUS for it.
Some other comments from me. I am not going to include such big changes into hcid. This is development work for the new security manager or call it device manager which is going to replace hcid.
Fredrik, would you please start a new post on the bluez-devel mailing list, so we have a new thread for it. This is not really GNOME related and I am not a big friend of cross-posting.
Regards
Marcel
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
Marcel Holtmann
maintainerHi Fredrik,
Quoted 4 lines
Similar to the idea with
/etc/bluetooth/keytab.socket, additional sockets can be created for other Bluetooth interface services such as name scans, lookups etc. Regular users have access to these capabilities based on socket file permissions.
the best place for Unix sockets is /tmp
Quoted 6 lines
Example:
/etc/bluetooth/names # The device name cache /etc/bluetooth/names.conf # The device name configuration file /etc/bluetooth/names.socket # The command socket
Quoted 8 lines
Command examples:
SCAN - Returns something similar to "hcitool scan"
LOOKUP <bdaddr> - Returns the name if available in the names file DELETE <bdaddr> - Removes the name from the names file
LIST - Lists all names in the names fileThe hcitool utility can be extended with these features too.
If we do it, this should be part of the Bluetooth library itself, so programmers don't have to worry about it.
Regards
Marcel
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
Re: [Bluez-devel] name cache
In reply to Fredrik NoringQuoted 4 lines · Fredrik Noring
Similar to the idea with
/etc/bluetooth/keytab.socket, additional sockets can be created for other Bluetooth interface services such as name scans, lookups etc. Regular users have access to these capabilities based on socket file permissions.
..
Quoted 2 lines
Command examples:
SCAN - Returns something similar to "hcitool scan"
This would only duplicate interfaces, since you can do it via HCI already.
Quoted 3 lines
LOOKUP <bdaddr> - Returns the name if available in the names file DELETE <bdaddr> - Removes the name from the names file
LIST - Lists all names in the names file
LIST should return the list of all seen addresses, since names are not necessarily unique. Additionally there could be something like RESOLVE_NAME "<name>" and LAST_SEEN <bdaddr>..
Just like the key management it might be cleaner to use DBUS for it.
greetings
Fred
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Quoted 1 line · Marcel Holtmann
the best place for Unix sockets is /tmp
Or /var/<something>, and not only sockets, but other variable data as well. /etc may be on a read-only filesystem. Imagine a bluetooth gadget based on Linux burnt in ROM.
(I continue to think that binary helper is a viable option for the low level interface. It is very scalable: "lean" implementation for very simple environments may be cut down to just a few lines of shell script. "Rich" implementation may use whatever database, and/or relay requests to other programs over D-BUS, or CORBA, or anything...)
Eugene
Marcel Holtmann
maintainerHi Eugene,
Quoted 5 lines
Quoted 1 line
the best place for Unix sockets is /tmp
Or /var/<something>, and not only sockets, but other variable data as well. /etc may be on a read-only filesystem. Imagine a bluetooth gadget based on Linux burnt in ROM.
No. The /tmp directory will be cleared on every boot and the Unix socket must not survive reboots. We can use /var/bluetooth for our databases.
Quoted 5 lines
(I continue to think that binary helper is a viable option for the low level interface. It is very scalable: "lean" implementation for very simple environments may be cut down to just a few lines of shell script. "Rich" implementation may use whatever database, and/or relay requests to other programs over D-BUS, or CORBA, or anything...)
Calling an extra program for every transaction "costs" too much and it raises too many security issues. If you talk about the PIN helper I think we would have in future per BD_ADDR stored PIN's, D-BUS and calling a helper script.
Regards
Marcel
_______________________________________________
gnome-bluetooth mailing list
[email protected]
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
Marcel,
fre 2004-01-30 klockan 19.18 skrev Marcel Holtmann:
Quoted 3 lines
This makes you independent from the database format (I prefer Berkeley DB at the moment) and you don't need to have database code in the Bluetooth library.
A built-in ASCII table format for all (or most) services is important, I think, because that's extremely lightweight and efficient for the common cases. It should be the default.
There can be support for various database client libraries as well (MySQL, LDAP, Oracle, Berkeley and whatever someone likes). Using any of those is a matter of:
1. Linking with the appropriate database client library.
2. Writing a proper configuration in hcid.conf.
Quoted 2 lines
But when we design it this way, we must make sure that we have the highest security for the link key transactions.
Some database clients support SSL, if that's required. I think such option ought to be decided by the administrator.
Quoted 2 lines
Additional commands can be NAME or ISPAIRED, but I am also not sure if a binary protocol would be better. Maybe we can use D-BUS for it.
Yes, maybe.
Quoted 3 lines
Some other comments from me. I am not going to include such big changes into hcid. This is development work for the new security manager or call it device manager which is going to replace hcid.
Why? (I'm sure all this can be backwards compatible with current hcid.) I think it's a good idea to work with the current code base in any case.
Quoted 3 lines
Fredrik, would you please start a new post on the bluez-devel mailing list, so we have a new thread for it. This is not really GNOME related and I am not a big friend of cross-posting.
Sure! This is technical now.
Fredrik
Hi Marcel,
fre 2004-01-30 klockan 19.26 skrev Marcel Holtmann:
Quoted 1 line
the best place for Unix sockets is /tmp
Agreed. Perhaps we can have a directory structure similar to this:
/tmp/hcid/keytab.socket
/tmp/hcid/nametab.socket
...
and so on for each kind of service. This will allow flexible user access permissions.
Quoted 2 lines
If we do it, this should be part of the Bluetooth library itself, so programmers don't have to worry about it.
Good idea.
Fredrik
Hi Eugene,
fre 2004-01-30 klockan 19.49 skrev Eugene Crosser:
Quoted 2 lines
/etc may be on a read-only filesystem. Imagine a bluetooth gadget based on Linux burnt in ROM.
I suppose this easily can solved with a symlink? (Although I agree with Marcel that /tmp is a better place.)
Quoted 5 lines
(I continue to think that binary helper is a viable option for the low level interface. It is very scalable: "lean" implementation for very simple environments may be cut down to just a few lines of shell script. "Rich" implementation may use whatever database, and/or relay requests to other programs over D-BUS, or CORBA, or anything...)
How are you going to setup access permissions for the services with your binary helpers? That's easy using sockets.
Fredrik
Re: [Bluez-devel] name cache
In reply to Fred SchättgenHi Fred,
fre 2004-01-30 klockan 19.49 skrev Fred Sch=E4ttgen:
Quoted 1 line
This would only duplicate interfaces, since you can do it via HCI alrea=
dy.
The hcid service is a big duplicate interface for HCI. :) But the important thing is that hcid provides these things:
1. Persistent configurations and data across reboots.
2. Flexible permissions management through the filesystem (using files and possibly sockets).
3. Resource sharing between applications (e.g. caches).
Quoted 1 line
Just like the key management it might be cleaner to use DBUS for it.
Sorry, I meant that just to be pseudo commands. The final protocol syntax probably looks totally different.
Fredrik
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel