Alon Bar-Lev wrote:
> On 1/21/09, Stanislav Brabec <sbra...@suse.cz> wrote:

> > 1) There are applications, that need direct access to the reader, not
> >  using pcsc-lite (example: cyberjack utilities). That is why it should
> >  allow to access not only to pcsc daemon, but also to users.
> 
> This is why you have udev, right?
> I never understood this hal thing...
> Why do you need special keywords, while the devices are standard USB
> or PCMCIA devices...

Yes, udev supports it as well. But most vendors prefer HAL for this
purpose nowadays.

Using of HAL could bring several benefits:
- splitting of "information" (e. g.: this USB device is a known Smart
  Card Reader, this /dev/ttyS0 is not a modem, but a Smart Card reader)
  and "policy" (is it a smart card reader => call pcscd --hotplug).
- HAL can support non-trivial probers, that can identify devices more
  exactly than udev can do (e. g. which device hangs on serial port,
  scan for partitions)
- GUI device viewers can correctly identify device type
- Applications can easily implement device list change event listening,
  even without root access.

There are also cons:
- HAL is not so straight forward as udev.
- In future it will be probably replaced by DeviceKit.

My current intention was:
- Define HAL standard keywords for smart card readers (and maybe for
  their features).
- Identify all Smart Cards by HAL.
- Define access policy
- And finally move pcscd hotplug from udev to hal. With a bit of
  configuration, it may support serial port readers.

> >  PolicyKit can ensure, that only users physically sitting at the desk can
> >  use the card.
> 
> As long as you don't use daemon to access these.
> 
> >  2) Up to now, HAL has no keyword for these devices and cannot report its
> >  presence.
> >
> >  HAL can easily recognize this device type (at least for USB). It allows
> >  to write simple applications: If smart card reader/token is plugged, do
> >  something (e. g. launch banking application).
> 
> For which user? And what happens if you have several applications? How
> do you control which do what?

HAL provides only an infrastructure to any (e. g. desktop) application.
Any HAL listener then knows, that smart card reader was attached.

One of example features, that can be easily implemented in Display
Manager with HAL:

Smart card token is just plugged => read it, auto-login user
Smart card token is just unplugged => save and kill the session, logout

You can argue, that it is possible just now directly with pcscd. Yes, it
is true. But HAL level implementation is more flexible: With a few
changes of code, you may reprogram it to use USB memory flash stick
serial# instead of Smart Card.

And it is scalable: With a bit of coding (not in my plan), HAL may make
possible to poll for card insertion/removal (exactly as it does polling
of CD/DVD insertion/removal).

Example in Shell:


Nowadays:

dbus-monitor --system

signal sender=:1.538 -> dest=(null destination) 
path=/org/freedesktop/Hal/Manager; interface=org.freedesktop.Hal.Manager; 
member=DeviceAdded
   string "/org/freedesktop/Hal/devices/usb_device_76b_3821_noserial"
signal sender=:1.538 -> dest=(null destination) 
path=/org/freedesktop/Hal/Manager; interface=org.freedesktop.Hal.Manager; 
member=DeviceAdded
   string "/org/freedesktop/Hal/devices/usb_device_76b_3821_noserial_if0"

lshal | sed -n 
'\:/org/freedesktop/Hal/devices/usb_device_76b_3821_noserial_if0:,/^$/p' | grep 
'info.\(category\|capabilities\)'
(no output, no information)


With simple HAL Smart Card support:

lshal | sed -n 
'\:/org/freedesktop/Hal/devices/usb_device_76b_3821_noserial_if0:,/^$/p' | grep 
'info.\(category\|capabilities\)'
  info.category = smart_card_reader
  info.capabilities = { 'smart_card_reader' }


With advanced HAL Smart Card support (just an example and subject of 
discussion):

lshal | sed -n 
'\:/org/freedesktop/Hal/devices/usb_device_76b_3821_noserial_if0:,/^$/p' | grep 
'info.\(category\|capabilities\)'
  info.category = smart_card_reader
  info.capabilities = { 'smart_card.reader.class3', 
'smart_card.reader.card.iso', 'usb_ccid' }

For other devices it may be for example smart_card.reader.card.iso 
smart_card.reader.card.sim
smart_card.reader.token etc.


-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbra...@suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to