Edd,
tis 2003-11-04 klockan 01.47 skrev Edd Dumbill:
> We need a way of finding out for which bdaddrs it has a key. Currently
> this information is stored in /etc/bluetooth/link_key and 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
(..persistent device name cache..)
> tor 2004-01-29 klockan 12.30 skrev Fred Sch=E4ttgen:
> > 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
> 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
Hi Fred,
fre 2004-01-30 klockan 19.49 skrev Fred Sch=E4ttgen:
> 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).
> 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
Hi Eugene,
fre 2004-01-30 klockan 19.49 skrev Eugene Crosser:
> /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.)
> (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
Hi Marcel,
fre 2004-01-30 klockan 19.26 skrev Marcel Holtmann:
> 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.
> 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
Marcel,
fre 2004-01-30 klockan 19.18 skrev Marcel Holtmann:
> 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.
> 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.
> 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.
> 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.
> 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 Eugene,
> > 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.
> (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
On Friday 30 January 2004 19:10, Fredrik Noring wrote:
> 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.
..
> Command examples:
> SCAN - Returns something similar to "hcitool scan"
This would only duplicate interfaces, since you can do it via HCI already.
> 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
On Fri, 2004-01-30 at 21:26, Marcel Holtmann wrote:
> 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
Hi Fredrik,
> 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
> 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.
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
Hi Fredrik,
> 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.
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
tor 2004-01-29 klockan 21.19 skrev Fred Sch=E4ttgen:
> I also think that wouldn't be misplaced in bluez. But since it can be e=
asily=20
> done with a gnome/kde service, this proposal will surely go to the bott=
om=20
> 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
Edd and Marcel,
tor 2004-01-29 klockan 16.32 skrev Edd Dumbill:
> 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
Hi Fred
tor 2004-01-29 klockan 12.30 skrev Fred Sch=E4ttgen:
> 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
Edd,
tor 2004-01-29 klockan 16.32 skrev Edd Dumbill:
> 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.
> Well, that, and the ability to delete a link key.
By invoking /sbin/hcid with a special unlink argument?
Fredrik
On Thu, 2004-01-29 at 15:22, Marcel Holtmann wrote:
> Hi Edd,
>
> > 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
Hi Edd,
> 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
On Thursday 29 January 2004 01:50, Fredrik Noring wrote:
...
> 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?
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
On Thu, 2004-01-29 at 00:50, Fredrik Noring wrote:
> 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
Hi
> 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
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