Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Edd Dumbill]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Marcel Holtmann]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Edd Dumbill]

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

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Marcel Holtmann]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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

Re: [Bluez-devel] Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Fred Schättgen]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [Bluez-devel] Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [Bluez-devel] What stuff in gnome-bluetooth does, and ideas for its future

[Fred Schättgen]

(..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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[gnome-bluetooth] Re: [Bluez-devel] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [gnome-bluetooth] Re: [Bluez-devel] What stuff in gnome-bluetooth does, and ideas for its future

[Marcel Holtmann]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [gnome-bluetooth] Re: [Bluez-devel] What stuff in gnome-bluetooth does, and ideas for its future

[Eugene Crosser]

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

Re: [gnome-bluetooth] Re: [Bluez-devel] What stuff in gnome-bluetooth does, and ideas for its future

[Marcel Holtmann]

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
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth

Re: [gnome-bluetooth] Re: [Bluez-devel] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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

Re: [gnome-bluetooth] Re: [Bluez-devel] What stuff in gnome-bluetooth does, and ideas for its future

[Fredrik Noring]

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

Re: [Bluez-devel] name cache

[Fred Schättgen]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] name cache

[Fredrik Noring]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel