Mantis Bugtracker

Простой вид комментарии ] расширенный вид ] история ] печать ]
Номер Категория Серьезность Воспроизводимость Создан Изменен
0000145 [obex-data-server] General нововведение всегда 2008-10-30 03:14 2009-01-18 17:16
Инициатор Jo Видимость общая  
Ответственный
Приоритет обычный Решение открыт  
Состояние назначен   Версия продукта 0.4.1
Суть 0000145: Two level security mode support in ODS
Подробности Recently I have read bluetooth obex specifications (GOEP, OPP, FTP) regarding the security mode. There are two levels of security check for the object exchange.

1. OBEX authentication
When the client tries to connect to a OBEX server, server may ask the user whethre to accept the incoming connection or not. ODS should suspend the client connection waiting for the accept/reject response from the user.
This feature is not used in OPP but should be implemented in FTP according to the spec. So I think ODS should have one more step of authentication for the initial FTP conneciton.

2. File authentication
Currently ODS suspends when a client pushes a file to a server but I think ODS should also be able to suspend when a client pulls a file form a server, e.g., FTP get operation. I didn't check the spec but confirmed this feature in commercial phones.

How do you think about this, Tadas?
Дополнительные сведения
Tэги Нет прикрепленных тэгов.
Вложенные файлы

- Связи

-  Комментарии
(0000496)
skirsdeda (администратор)
2008-10-30 20:43

1. I don't think that the first situation is important for us. CreateBluetoothServer has require_pairing argument which ensures that the devices are paired prior to doing any OBEX transfers. If devices are paired already, it should be considered safe to accept transfers from that device.
2. That is possible, but again for FTP require_pairing should be set.

Does this make sense to you?
(0000500)
Jo (инициатор)
2008-11-03 16:55

1. Regardless of the pairing status, the client device should be asked for the OBEX authentication unless it is authorized locally in FTP server side. Pairing does not mean the client device is always trusted. So I think asking user whenever there comes a new OBEX session makes sense.
2. Same reason :)
(0000501)
skirsdeda (администратор)
2008-11-11 17:10

I just realized that it might be possible to implement this quite easily by letting Bluez handle the authorization.
(0000502)
Jo (инициатор)
2008-11-12 10:42

That's a good news.
Do you mean OBEX authorization and all put/get/delete authorization stuffs might be possible through BlueZ?
I totally agree that a common authorization module should exist for all those procedures.
(0000503)
Jo (инициатор)
2008-11-12 11:38

By the way, the openobex 1.4 was released :)
(0000508)
skirsdeda (администратор)
2008-11-29 17:01

Unfortunately, it is not possible to do this via Bluez API because ods uses plain libbluetooth to store SDP records. We have to think of some other way...
(0000520)
Jo (инициатор)
2009-01-17 10:13

Welcome back, Tadas.

Recently I have worked around for the authorization/authentication procedures for the BT profiles relevent to OBEX and noticed that OBEX authentication is a mandatory requirement to support in GOEP based profiles. It's written in chapter 2.4, GOEP and the detailed spec is in OBEX protocol spec. But it's not implemented in openobex 1.4. I asked to the openobex mailing list and found that obexpushd 0.8 supports OBEX authentication procedure without guarantee. The maintainer of obexpushd, Hendrik, wrote a patch for it and sent to the openobex community. So basically OBEX authentication is not supported in current openobex and I misunderstood it in this bug report.

The one I asked in this bug report is the authorization procedure which bluez provides through a dbus authorization agent. When I tried to use the "RequestAuthorization" API, bluez couldn't find the relevent record because it's not registered by "AddRecord" dbus call as you have wrote in the previous comment. For now I have modified the bluez service.c file locally and passed the required uuid and name filed. However I think if ODS registers the SDP by the dbus call it will be a no problem, which is not easy though :)

Thanks and hope you spend a wonderful time in Oslo.
(0000521)
skirsdeda (администратор)
2009-01-18 17:16

Refactoring ods to use XML records would require quiet some effort. I'd rather if bluez dbus interface supported authorization procedures for binary SDP records. I haven't really investigated how authorization is implemented in bluez so it's still difficult to say which option is the best.

And thanks for welcoming :)

- история
Дата изменения Пользователь Поле Изменение
2008-10-30 03:14 Jo Новый вопрос
2008-10-30 20:43 skirsdeda Комментарий добавлен: 0000496
2008-11-03 16:55 Jo Комментарий добавлен: 0000500
2008-11-11 17:10 skirsdeda Комментарий добавлен: 0000501
2008-11-11 17:10 skirsdeda Состояние новый => назначен
2008-11-12 10:42 Jo Комментарий добавлен: 0000502
2008-11-12 11:38 Jo Комментарий добавлен: 0000503
2008-11-29 17:01 skirsdeda Комментарий добавлен: 0000508
2008-12-01 03:57 Jo Комментарий добавлен: 0000512
2009-01-17 10:11 Jo Комментарий удален: 0000512
2009-01-17 10:13 Jo Комментарий добавлен: 0000520
2009-01-18 17:16 skirsdeda Комментарий добавлен: 0000521


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker