On 1/22/09, Stanislav Brabec <sbra...@suse.cz> wrote: > 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.
vendors? You mean Novell, right? > 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). OK... Don't see benefit here except of some better Windows like device manager. But except of presenting it to the user, what should the user do with the information? For USB it is easy, no need to change anything in pcscd and openct. > - 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) Nothing relevant here. > - GUI device viewers can correctly identify device type Great! But GUI can be separate. > - Applications can easily implement device list change event listening, > even without root access. This can be done via the reader frameworks... pcsc/openct. > There are also cons: > - HAL is not so straight forward as udev. This is why I don't use it. Just takes CPU and other resources. No way to configure it easily. > - In future it will be probably replaced by DeviceKit. Oh... So hal failed. Why invest more? > My current intention was: > - Define HAL standard keywords for smart card readers (and maybe for > their features). > - Identify all Smart Cards by HAL. Smartcards or readers? I guess you mean smartcard. > - Define access policy Only pcscd/openct can access. openct already uses udev in order to do this, nothing else is needed. pcscd cannot run as none root... > - And finally move pcscd hotplug from udev to hal. With a bit of > configuration, it may support serial port readers. I think it is already implemented using hal. One of the reasons why I turned to openct. > HAL provides only an infrastructure to any (e. g. desktop) application. > Any HAL listener then knows, that smart card reader was attached. The problem is that smartcards should be used in other environments as well... For example at my initramfs I have application that access the smartcard in order to decrypt the root filesystem. In servers I use smartcards with ssh. Servers such as OpenVPN accesses the readers as well. Adding hal dependency to these components is not wise. It makes command-line only and server installation must more difficult. Low level devices should be handled by udev. Hal is great for devices that should be managed by users (removable media, cameras). > 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 And if the user already logged on? In which desktop will it run? How will it request passphrase? This should be implement in greeter application of KDM or GDM, not by hal. > Smart card token is just unplugged => save and kill the session, logout And if you have two plugged in? The pam_pkcs11 has a simple process that takes care of this without any complex configurations. > 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?!?!?!? > 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). Polling is bad. I just added support for openct to stop polling. Modern applications should not poll. I am truly sorry... But I don't see the benefit. Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
