Re: [opensc-devel] Making a module driver on opensc-0.11.6
On 1/23/09, Andreas Jellinghaus wrote: > > It cannot be unless we explicitly specify some exceptions in OpenSC > > license. A plugin for LGPL should be also GPLed. > > Read [1] and on. > > > opensc is not under GPL. GPL and LGPL are the same, except of that none GPLed application can be linked with LGPLed application. But LGPL application/library cannot have none GPLed dependencies. This is to allow GPLed application use LGPLed application without breaking GPL chain. So the rules of having a plugin to GPL or LGPL should be the same. PKCS#11 or any standard interface which is not depended on a specific implementation, is an edge condition I discussed with FSF and they agreed that as long the application and the provider have not implicit or explicit knowledge about each other it is OK. You cannot say this on openct plugin as it is openct specific. I hope this helps. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
On 1/23/09, Andreas Jellinghaus wrote: > > 3. pcscd must run as root... A none root mode may be supported but > > never implemented. > forgive me, but usb control transfer ioctl can only be done as root I thought? > thus anyone trying these on a usb device needs root? or is write access to > the device enough? No... mdev/udev/hal can set permission on the device so that the daemon can access it using none root account. Look at recent openct. > > 4. Due to the threading limitation of libusb or kenrel pcscd polls > > readers every 2 seconds which waste CPU and power resources. > the kernel had a bug not dealing with properly disconnected usb > devices, thus they have to - and openct does (did?) the samething. No... this is not the case. There is an issue with libusb and threading or whatever. Nothing relevant to coldplug. See Ludovic description [1][2]. [1] http://www.nabble.com/event-handling-and-canceled-thread-issue-(again)-to20794059.html [2] http://thread.gmane.org/gmane.comp.lib.libusb.devel.general/ > > 5. The udev support was dropped in favor of hal, which added > > dependency for all scenarios. > > openct users are often confused by the many choices they have. > not sure it is such a bad thing to reduce the number of supported > options. Yes it is, if you add new dependencies. Which are not *MUST* have. > > 6. The libusb support polls the USB bus... So it is irrelevant. > > well, if you aim to support non-linux, watching the usb bus yourself > seems to be the best or only option you have to notice new devices > etc. also watching usb is much simpler than the hotplug/udev/hal > maze which needed many changes over the years. openct does coldplug in many OSes without libusb... You don't need to watch... The main problem is the coldplug. Anyway... Worse scenario... You can always ask hal to enumerate devices for you :) > > While openct... > > 1. Much simpler. > > but it cannot match the features pcscd has, does not even come close. True. This why I suggest we work together in order to combin the best of these two solutions. Take the 1 process per reader feature and simplicity of openct. Take the pcsc API which can be a simple library (No need for pcscd). Make the pcsc API communicate with the reader processes via sockets. Allow also openct API to communicate with the same processes. Or any other implementation. We do not need two competing projects Separating between the device management and the API exposed to applications, simplify the code to handle readers, and allow reuse of drivers in many types of applications will enable us to focus resources on improving the features to users. > > 4. Does not use hal or libusb. > > hu? how does openct implement coldplugging these days? > that code always depended on libusb. Only for Linux and as I don't have usbfs on my system I removed this as well. > > 6. At least ccid and etoken drivers does not poll devices. > what about the core, how do we detect if a driver was unplugged? Using signal from the kernel. Without usbfs feature of kernel there was a bug I found, it will be available (hopefully) in the next stable 2.6.28. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Making a module driver on opensc-0.11.6
Am Donnerstag 22 Januar 2009 19:34:10 schrieb Alon Bar-Lev: > On 1/22/09, Jeffrey Hutzelman wrote: > > provide source. I think it's also important to consider cases where > > there _is_ an open-source driver, but with a GPL-incompatible license. I'm not aware of any open-source driver for opensc with a GPL-incompatible license. > It cannot be unless we explicitly specify some exceptions in OpenSC > license. A plugin for LGPL should be also GPLed. > Read [1] and on. opensc is not under GPL. Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Making a module driver on opensc-0.11.6
Am Donnerstag 22 Januar 2009 18:49:07 schrieb Alon Bar-Lev: > > I think we should discuss this scenario: > > is it ok if someone uses opensc, changes it as he likes, and published > > the resulting code and binaries - with one file only published as *.o > > (his new card driver)? I guess that captures the spirit of the LGPL quite > > nicely and is quite usable too. (but I have not checked the wording of > > the LGPL to find out if that is ok, and I'm no lawyer either...) > > The driver is consider plugin in FSF terms, and it needs to be GPLed as > well. wait! opensc is under LGPL, so there is no GPL here. of course if you want to login with your smart card, the problem is that login and kdm/gdm might be GPL'ed and they load pam which loads e.g. pam_p11 which loads libp11 which loads opensc-pkcs11.so which loads libopensc.so which might load your binary only driver. but that is only runtime, not a compiled binary consisting of different parts, and this chain uses standard interfaces enabled by the author of each part. so I'm not 100% certain if this situation is ok or not. also don't forget the clauses for system libraries (and pam is one) in the gpl. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Am Freitag 23 Januar 2009 01:49:05 schrieb Peter Stuge: > Andreas Jellinghaus wrote: > > if anyone wants to walk into the opposite direction, write a daemon > > that monitors usb and then acts on any change, that is fine with me > > - I think pcscd does exactly that? not sure. > > Implementation should be simple at least for Linux. yes and no. it would be simple to scan the usb bus every 0.5 seconds and compare the result to the last scan to see if anything changed. but if you want to save power on laptops and idle as much as you can, I guess the code you need will be much more complex. also it might be difficult to write such code cross-plattform. at least mac OS X has a very different usb interface, and I'm not sure if libusb can abstract away all the pain of two different designs. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Am Freitag 23 Januar 2009 06:51:13 schrieb Alon Bar-Lev: > On 1/22/09, Jeffrey Hutzelman wrote: > > How do you propose for USB device drivers to talk to their devices, if > > not using libusb? Remember, we'd like to be portable here; the whole > > world's not Linux. > > openct does not use libusb for communicating with usb even before I > know it exists... :) the reason for this was: the kernel does usb monitoring and told us by running /sbin/hotplug "there is a new usb device" and included the path in /proc/bus/usb. with libusb there was no way to map that path to the libusb structures. we would need to parse the path for host and device number, than have libusb scan the bus, enumerate all devices and look for the device we want. not nice. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
> 3. pcscd must run as root... A none root mode may be supported but > never implemented. forgive me, but usb control transfer ioctl can only be done as root I thought? thus anyone trying these on a usb device needs root? or is write access to the device enough? > 4. Due to the threading limitation of libusb or kenrel pcscd polls > readers every 2 seconds which waste CPU and power resources. the kernel had a bug not dealing with properly disconnected usb devices, thus they have to - and openct does (did?) the samething. > 5. The udev support was dropped in favor of hal, which added > dependency for all scenarios. openct users are often confused by the many choices they have. not sure it is such a bad thing to reduce the number of supported options. > 6. The libusb support polls the USB bus... So it is irrelevant. well, if you aim to support non-linux, watching the usb bus yourself seems to be the best or only option you have to notice new devices etc. also watching usb is much simpler than the hotplug/udev/hal maze which needed many changes over the years. > While openct... > 1. Much simpler. but it cannot match the features pcscd has, does not even come close. > 4. Does not use hal or libusb. hu? how does openct implement coldplugging these days? that code always depended on libusb. > 6. At least ccid and etoken drivers does not poll devices. what about the core, how do we detect if a driver was unplugged? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Sorry Peter, I have no clue how you make the connection from usb interrupt mode to hal. from my point of view udev is unstable and changes in udev broke the udev/openct setup several times. the udev/hotplug/linux-usb folks recommend to use hal instead, which so far is working fine. so why not use hal? sure, on embedded systems an extra daemon with memory needs is not very welcome. but on the normal desktop, that is no concern. also please be kind to stanislav. it is great if distributions discuss their plans with it. I don't remember other distributions doing this, so I welcome this opportunity a lot. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
On 1/22/09, Jeffrey Hutzelman wrote: > How do you propose for USB device drivers to talk to their devices, if not > using libusb? Remember, we'd like to be portable here; the whole world's > not Linux. openct does not use libusb for communicating with usb even before I know it exists... :) This is why it is much simpler... I know that abstraction should have made it easy but libusb was unmaintained for many years, and the async support was added only recently for a new major of the library... And it still not perfect. Not always using abstraction is the best solution. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Andreas Jellinghaus wrote: > if anyone wants to walk into the opposite direction, write a daemon > that monitors usb and then acts on any change, that is fine with me > - I think pcscd does exactly that? not sure. Implementation should be simple at least for Linux. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Stanislav Brabec wrote: > On the link level, USB interrupt mode is based on periodical > re-submitting of the interrupt URB. Yeah. USB devices can be put to sleep and signal wakeup too. Seems our opinion is that HAL is bloat and bad for life. Your situation does not align with this. Obviously you will add this to HAL whatever the list says. If you want to be smooth you could use some of that HAL flexibility to at least make sure that HAL is the bitch of pcsc-lite/openct? Please? Thanks. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Multislot readers?
Martin Paljak wrote: > AFAIK we don't support any wireless things. librfid [http://openmrtd.org/] can use OpenCT for wireless things. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Am Donnerstag 22 Januar 2009 18:57:19 schrieb Alon Bar-Lev: > On 1/22/09, Andreas Jellinghaus wrote: > > using udev was a huge pain for many years, everytime I thought "now it > > works", a few months later openct didn't work with the new udev. I'm > > sick of that pain, and since the udev/hotplug/linux-usb folks tell us to > > use hal, and hal seems to work, I think it is best to take their advice > > and do that: use hal! > > It works correctly for me. > Maybe I miss something. > The changes in udev were minor and were not a reason to add more > dependency. some combination of udev rules found in the real world, would cause udev to call the openct udev script before udev created the device file in /dev/bus/usb. at the same time distributions stopped using /proc/bus/usb (because they could put ACLs on /dev/bus/usb and favored it that way). sure, even such race conditions could be worked around (fork, sleep 1 sec, now the device should be there), but it still was annoying. this is only one example how openct got broken by udev. another time an essential info passed from kernel to userland for the hotplug events was missing, and needed to be re-added later. anyway, old stories, long closed. using hald is supported upstream and easier, thus it is the recommend way from my point of view. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
> information: Identify selected devices.
> info.category = 'smart_card_reader'
> info.capabilities = { 'openct' }
openct or some other software should not matter IMO, why make it a capability?
> Good idea! But iso7816 could make it more cryptic to ordinary users.
right. stick with "smart_card_reader" category and hope we don't need to
explain that a "smart_card_reader" is not a "smart media card reader"
too often? :)
> I can imagine:
> info.category = 'smart_card_reader'
> info.capabilities = { 'openct', 'iso7816', 'smart_card_reader', 'usb_ccid'
ccid shouldn't matter. do you need to put the category as capability too?
we should have "display" and "pinpad" if capabilities are defined per category.
if not, the capability name needs to be longer, so "display" is not mistaken
with displays (e.g. monitors, lcd etc.).
> I expect one another change in near future: Fedora people will say "Use
> DeviceKit instead of hal."
maybe we can get their devicekit config file and document how to configure
device kit, so other distributions don't need to re-invent the wheel.
Regards, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
--On Thursday, January 22, 2009 06:50:34 PM +0100 Andreas Jellinghaus wrote: > more complex operations such as "upload new firmware > to card reader" will most propably never work with pcscd (guessing only, > I'm no expert here). I think that's going to depend on the reader driver. There certainly is a reader-level IFDHControl operation which could do pretty much arbitrary operations. Of course, such operations are likely to require close cooperation between the reader and application. OTOH, I don't think you want non-privileged users uploading new firmware to devices anyway. > my personal recommendation is: > * use libccid + pcsc-lite for all smart card readers and applications Well, all CCID readers, anyway. Obviously you need a different driver for non-CCID readers. > * yes, that means not using openct. we need to admit, that openct >has no proper pin entry code for readers with display and pinpad. Or openct could be improved in this area. Currently my preference is to continue using pcsc-lite, but as you can tell from the discussion Alon and I have been having, there are definitely tradeoffs involved. > * yes, that also means not using the (most likely binary only?) code >the vendor published. I'm pro open source here, sure. also I think >distributions are much better off with one generic software, than >they are with many vendor-specific incompatible solutions. I'm pro-open-source, too, but not to the exclusion of people being able to get work done. Open source is a means to an end, not an end in itself, and too often its advocates forget that. > also I want to point out, that people might want to use smart card readers > for authentication. hal seems to be very gui-desktop centric, if I'm not > mistaken? Not really. HAL is an abstraction for device enumeration. It's not GUI-desktop-centric at all, but many of its current users are. > (people still seem to use /etc/fstab to mount there filesystems, > and not a hal config file) That's because most people aren't insane, and other than for certain special cases (mostly, removable media), HAL doesn't offer any improvement in this area over the existing model. > using udev was a huge pain for many years, everytime I thought "now it > works", a few months later openct didn't work with the new udev. I'm sick > of that pain, and since the udev/hotplug/linux-usb folks tell us to use > hal, and hal seems to work, I think it is best to take their advice and > do that: use hal! udev went through a lot of growing pains. I think that's been over for a while, but I haven't been watching closely, so I may be wrong. I'm perfectly happy to use HAL in situations where it's appropriate, but I agree with Alon that HAL is not appropriate for every situation. Particularly, it's unneeded complexity in embedded environments where there are a small number of possible hardware configurations and they don't change much. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
--On Thursday, January 22, 2009 08:49:33 PM +0200 Alon Bar-Lev wrote: > Poll the reader to detect card insert. Yeah, that's still a problem, and certainly one I'd like to see fixed. It's also per-driver, and I'm not sure it even _can_ be fixed for all kinds of devices. >> > 5. The udev support was dropped in favor of hal, which added >> > dependency for all scenarios. >> > >> >> Nothing was dropped in favor of HAL. It is possible to configure pcscd >> to use HAL for USB device detection, but it is by no means mandatory, >> and it is still possible to inform pcscd of new devices by running pcscd >> --hotplug, whether or not it is compiled with HAL support. > > The rules are not provided nor maintained. Hm. Shouldn't they come with the individual drivers, rather than with pcsc-lite itself? I certainly intend to provide udev rules with ifd-egate, as soon as I can figure out what they need to be. >> >> > 6. The libusb support polls the USB bus... So it is irrelevant. >> > >> >> Only if there are drivers that do not advertise IFD_GENERATE_HOTPLUG. >> If all drivers support hotplugging, then the USB bus is scanned only >> when someone runs pcscd --hotplug. It's true that on Linux there is no >> way short of HAL for pcscd to automatically detect new USB devices. As >> far as I know that has always been the case. > > Installing pcscd within mdev environment without libusb is quite > difficult. How do you propose for USB device drivers to talk to their devices, if not using libusb? Remember, we'd like to be portable here; the whole world's not Linux. > 1. Be usable in initramfs configuration, so that I can decrypt the > root filesystem. At this environment I don't have udev, hal or > usbfs... > 2. Drop libusb requirement for coldplug and use sysfs directly. Ouch. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Andreas Jellinghaus wrote:
> openct already has a fci file, adding some
> information into it so gui tools can identify
> the result is not a bad idea I guess.
It's my plan to start with this file. This file uses "smart_card_reader"
for category. HAL specification recommends to use two FDI files in this
context.
information: Identify selected devices.
info.category = 'smart_card_reader'
info.capabilities = { 'openct' }
policy: Perform actions on these devices.
if capabilities contain 'openct' then add hald-addon-openct to
info.addons.
Example for disabling of openct for particular reader by (with a few
changes, pcsc-lite can be handled in a similar way):
openct
> so please use "smart card reader" and friends. or even better, throw
> in "iso 7816" somewhere, as that technical term is the best way to clearly
> say what we are talking about.
Good idea! But iso7816 could make it more cryptic to ordinary users.
I can imagine:
info.category = 'smart_card_reader'
info.capabilities = { 'openct', 'iso7816', 'smart_card_reader', 'usb_ccid' }
But we can introduce new keywords to not overload 'info.capabilities',
e. g. info.smart_card = { 'iso7816', 'usb_ccid' }
or even
info.smart_card.class = 3
I have no idea, what would be better in future.
> please don't use "card_reader", we already have trouble with people
> only knowing comptact flash / smart media cards / ... and being confused
> by what we call "smart card".
There are already CF/SM/... card readers, that support SIM cards as
well. That is why I can imagine 'card_reader.iso7816'.
> also I want to point out, that people might want to use smart card readers
> for authentication. hal seems to be very gui-desktop centric, if I'm not
> mistaken? (people still seem to use /etc/fstab to mount there filesystems,
> and not a hal config file)
It is not GUI-centric, it is GUI-helpful. Tools for console users with
HAL exist as well.
The very simplistic example of HAL <-> GUI:
USB dongle inserted -> IRQ -> kernel (load driver) -> udev (create /dev
node) -> hal (scan partitions contents) -> dbus -> GUI is listening:
"Device /...udi was inserted. It has following partitions with following
file systems."
GUI thinks and says: "OK. Please mount with these options." -> dbus ->
hal (gets a mount request) -> mkdir & mount -> kernel
Work is done. User does not need root privileges, but can still control
mount process or even completely reject.
People with a static devices configuration don't need HAL.
> using udev was a huge pain for many years, everytime I thought "now it
> works", a few months later openct didn't work with the new udev. I'm sick
> of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal,
> and hal seems to work, I think it is best to take their advice and do that:
> use hal!
I expect one another change in near future: Fedora people will say "Use
DeviceKit instead of hal."
> I have too little clue about the further developments of hal and policykit
> and what kde and gnome do, so I can't comment on that.
PolicyKit does not communicate with GNOME (with exception of local X
session registration). It only permits local access to ALSA and other
desktop centric devices.
--
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 Republichttp://www.suse.cz/
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
On 1/22/09, Jeffrey Hutzelman wrote: > --On Thursday, January 22, 2009 08:14:20 PM +0200 Alon Bar-Lev > wrote: > > > > Well, Ludovic knows my arguments... > > > > > > 4. Due to the threading limitation of libusb or kenrel pcscd polls > > readers every 2 seconds which waste CPU and power resources. > > > > Only if you have reader drivers which require this. If all of your reader > drivers support hotplugging, then pcscd does not need to poll. > Poll the reader to detect card insert. Even the ccid driver that can receive event polls every 2 seconds as it has some issues with threading. > > 5. The udev support was dropped in favor of hal, which added > > dependency for all scenarios. > > > > Nothing was dropped in favor of HAL. It is possible to configure pcscd to > use HAL for USB device detection, but it is by no means mandatory, and it is > still possible to inform pcscd of new devices by running pcscd --hotplug, > whether or not it is compiled with HAL support. The rules are not provided nor maintained. > > > 6. The libusb support polls the USB bus... So it is irrelevant. > > > > Only if there are drivers that do not advertise IFD_GENERATE_HOTPLUG. If > all drivers support hotplugging, then the USB bus is scanned only when > someone runs pcscd --hotplug. It's true that on Linux there is no way short > of HAL for pcscd to automatically detect new USB devices. As far as I know > that has always been the case. Installing pcscd within mdev environment without libusb is quite difficult. > But given your other arguments, I suspect we will have to agree to > disagree, and taking this much further is probably not productive. Right... :) I made some modifications in openct to make it feet into my requirements... This is after I tried very hard to use pcscd. 1. Be usable in initramfs configuration, so that I can decrypt the root filesystem. At this environment I don't have udev, hal or usbfs... 2. Drop libusb requirement for coldplug and use sysfs directly. 3. Run as none root to enhance security. 4. Do not poll readers, copied the basics from pcscd and made it completely event triggered. 5. Work correctly at system hibernation. But as Andreas wrote, openct still lack pinpad support, maybe if I have such device I will be able to add this feature as well. Thanks, Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
--On Thursday, January 22, 2009 08:14:20 PM +0200 Alon Bar-Lev wrote: > Well, Ludovic knows my arguments... > 4. Due to the threading limitation of libusb or kenrel pcscd polls > readers every 2 seconds which waste CPU and power resources. Only if you have reader drivers which require this. If all of your reader drivers support hotplugging, then pcscd does not need to poll. > 5. The udev support was dropped in favor of hal, which added > dependency for all scenarios. Nothing was dropped in favor of HAL. It is possible to configure pcscd to use HAL for USB device detection, but it is by no means mandatory, and it is still possible to inform pcscd of new devices by running pcscd --hotplug, whether or not it is compiled with HAL support. > 6. The libusb support polls the USB bus... So it is irrelevant. Only if there are drivers that do not advertise IFD_GENERATE_HOTPLUG. If all drivers support hotplugging, then the USB bus is scanned only when someone runs pcscd --hotplug. It's true that on Linux there is no way short of HAL for pcscd to automatically detect new USB devices. As far as I know that has always been the case. But given your other arguments, I suspect we will have to agree to disagree, and taking this much further is probably not productive. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Making a module driver on opensc-0.11.6
On 1/22/09, Jeffrey Hutzelman wrote: > provide source. I think it's also important to consider cases where there > _is_ an open-source driver, but with a GPL-incompatible license. It cannot be unless we explicitly specify some exceptions in OpenSC license. A plugin for LGPL should be also GPLed. Read [1] and on. Alon. [1] http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLAndPlugins ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Making a module driver on opensc-0.11.6
--On Thursday, January 22, 2009 06:24:58 PM +0100 Andreas Jellinghaus wrote: > my point of view is: > there is not a single external driver that I'm aware off. > thus we could remove the whole code for allowing external > loadable drivers, as there are none, and that would simplify > the code. Yes, and then you could totally give up on providing a well-defined interface for drivers, and then people wouldn't be able to have separately-maintained drivers, wehther or not we know or care about them. The Linux kernel people went that route, and it screws me more or less every day. So, more on principle than anything else, please don't do this. > about the internal/external situation: our long term goal > should be to allow only internal tool to use the internal > api, and suggest using the pkcs#11 interface to everyone. For applications, this is OK, more or less. I'm not sure that's good enough for tools that initialize cards, but it might be. > the only one using the internal api is openssh, and it can be ported > to pkcs#11 I'd like to see that. - alon has done that, but it is a part of a huge change that > is unlikely to find many adopters (my personal guess - I think people > like that ssh is very easy and simple, and adding x.509 results in a quite > complex thing I guess). ssh is not very easy and simple; it is a hugely complex protocol. That it looks easy and simple to its users is a testament to the excellent job many of its implementors have done. Support for X.509 certificates in the SSH protocol is something that has been talked about from time to time, first in the SECSH working group (now concluded) and more recently on its still-active mailing list. I've also seen mention of interest in a couple of other places. Note that getting _anything_ into OpenSSH is quite difficult; they are a bit overparanoid and, besides requiring adequate review, are sometimes very resistant to adding new functionality. > I think we should discuss this scenario: > is it ok if someone uses opensc, changes it as he likes, and published the > resulting code and binaries - with one file only published as *.o (his new > card driver)? I guess that captures the spirit of the LGPL quite nicely > and is quite usable too. (but I have not checked the wording of the LGPL > to find out if that is ok, and I'm no lawyer either...) I think that _should_ be OK -- the interface between card drivers and the framework is or should be a natural boundary, and I think it's self-defeating to basically tell people they can't use opensc (or any open-source software) with particular hardware not because the vendor is unwilling to provide a driver, but because they are unwilling or unable to provide source. I think it's also important to consider cases where there _is_ an open-source driver, but with a GPL-incompatible license. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Andreas Jellinghaus wrote: > Am Donnerstag 22 Januar 2009 15:54:07 schrieb Stanislav Brabec: > > > But why do you need to configure PolicyKit? What is the problem > > > PolicyKit is trying to solve? > > > > Grating access to users physically present at the computer. > > It uses standard UNIX ACL, so it can apply to both device nodes and > > sockets. > > so what happends with using smart cards readers for authentication > (including login)? It involves no change to smart card utilities. PolicyKit can just refuse access to pcscd by remote users (at least by default). And it can do the same for direct access, if we will permit it for local users. login -> PAM -> runs as root -> access permitted card use as local user -> PolicyKit permits access to pcscd -> pcscd has access permitted > asking people to install hald on a server without any gui already adds > many packages for no other good reason. I don't know much about > Policykit, but please keep the "server with minimal installation" scenario > in mind, where admins want to login using their smart card. You can live with static permissions and static references to device nodes, you can still live without both hal and udev. pcscd used hal just to listening to events. Compile time option allows to switch back to udev. -- 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 Republichttp://www.suse.cz/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
On 1/22/09, Jeffrey Hutzelman wrote: > > > > > Yes, udev supports it as well. But most vendors prefer HAL for this > > > purpose nowadays. > > > > > > > vendors? You mean Novell, right? > > > > Most of the major Linuxes, both commercial and otherwise. > I believe Sun is also going down this path. For GUI desktop I understand the need. But smartcards should be used also outside of this environment. > Yes, pcscd supports using HAL to detect hotplugging of USB devices. It > also supports using libusb directly, so not wanting to use HAL is not a > reason to abandon pcsc-lite. Please, come back. :-) Well, Ludovic knows my arguments... 1. pcscd is very complex. 2. pcscd uses a complex threading model, making it very hard to follow and debug. It also create many edge conditions when it tries to kill threads or manage signals (device remove and such). 3. pcscd must run as root... A none root mode may be supported but never implemented. 4. Due to the threading limitation of libusb or kenrel pcscd polls readers every 2 seconds which waste CPU and power resources. 5. The udev support was dropped in favor of hal, which added dependency for all scenarios. 6. The libusb support polls the USB bus... So it is irrelevant. While openct... 1. Much simpler. 2. Does not use threads. 3. Runs as none root. 4. Does not use hal or libusb. 5. Can be used with udev and mdev. 6. At least ccid and etoken drivers does not poll devices. I think that if we had enough resources we would have able to design and implement openct like reader process (ifdhandler) one process for every reader. And provide API interface both for PC/SC and CT. This way we enjoy the simplicity of one process per reader and the independent API for applications. These processes can be run using udev/mdev/hal while the API can communicate with these processes. Just a thought... Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
adding a few "info.capability" to the fci files is fine with me. the other side is: how these are evaluated. if I have a machine, where both gui access as well console login need the smart card reader, then giving exclusive rights to the one logged in, will break console login? I understand the things stanislav want to do, and agree they are nice. (I used to "play redalert.wav" in 93 in a linux mailbox and got the attention of the sysadmin quite fast :) ) but: unix user and groups don't work to implement this at all. (if you are once logged as gui user and e.g. are included in the audio group, then all you need to do is copy the shell, make it setgid audio and you are done - later a login on the ssh where you don't get the audio group, you can run that setgid shell). sure, the linux security modules stuff can prevent this scenario... my private opinion is, that a server granting access to authenticated users is the best way - X works fine that way e.g. and I think a central smart card daemon would be great, as you could e.g. enter the pin once during login and keep the card in a verified state so applications can use it without asking the user for the pin all the time. but we have no such software (and some people don't like the scenario), so that is only idle talk. suze can implement whatever they want, we can't stop them. and I think it is real nice of stanislav to contact us on the issue, and discuss the options they have, and synchronize e.g. which keywords to put into the hal fci file. I think that level of cooperation is great! which reminds me that I nearly never get any feedback from any distribution but from time to time went around and looked at their setup and changes and patches, as nearly noone would send patches back upstream. thus any cooperation from distribution to upstream is very nice and something we should be glad to have! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
On 1/22/09, Andreas Jellinghaus wrote: > using udev was a huge pain for many years, everytime I thought "now it > works", a few months later openct didn't work with the new udev. I'm sick > of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal, > and hal seems to work, I think it is best to take their advice and do that: > use hal! It works correctly for me. Maybe I miss something. The changes in udev were minor and were not a reason to add more dependency. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Am Donnerstag 22 Januar 2009 15:54:07 schrieb Stanislav Brabec: > > But why do you need to configure PolicyKit? What is the problem > > PolicyKit is trying to solve? > > Grating access to users physically present at the computer. > It uses standard UNIX ACL, so it can apply to both device nodes and > sockets. so what happends with using smart cards readers for authentication (including login)? asking people to install hald on a server without any gui already adds many packages for no other good reason. I don't know much about Policykit, but please keep the "server with minimal installation" scenario in mind, where admins want to login using their smart card. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
openct already has a fci file, adding some information into it so gui tools can identify the result is not a bad idea I guess. please don't use "card_reader", we already have trouble with people only knowing comptact flash / smart media cards / ... and being confused by what we call "smart card". so please use "smart card reader" and friends. or even better, throw in "iso 7816" somewhere, as that technical term is the best way to clearly say what we are talking about. I understand the distributions problems: they chose to ship the cyberjack utilities, and now need to live with the stupid design those have (direct access to the device). on the other hand I can't even blame them: while simple operations such as accessing a memory card should work well via pcscd, more complex operations such as "upload new firmware to card reader" will most propably never work with pcscd (guessing only, I'm no expert here). my personal recommendation is: * use libccid + pcsc-lite for all smart card readers and applications * yes, that means not using openct. we need to admit, that openct has no proper pin entry code for readers with display and pinpad. * yes, that also means not using the (most likely binary only?) code the vendor published. I'm pro open source here, sure. also I think distributions are much better off with one generic software, than they are with many vendor-specific incompatible solutions. also I want to point out, that people might want to use smart card readers for authentication. hal seems to be very gui-desktop centric, if I'm not mistaken? (people still seem to use /etc/fstab to mount there filesystems, and not a hal config file) using udev was a huge pain for many years, everytime I thought "now it works", a few months later openct didn't work with the new udev. I'm sick of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal, and hal seems to work, I think it is best to take their advice and do that: use hal! I have too little clue about the further developments of hal and policykit and what kde and gnome do, so I can't comment on that. if anyone wants to walk into the opposite direction, write a daemon that monitors usb and then acts on any change, that is fine with me - I think pcscd does exactly that? not sure. it would have saved me much, much time, if I had choosen that road many years ago. but at that time I thought it would be better to let the kernel do that, and get "signals" from the kernel (e.g. hotplug interface, later via udev). but now that hal+udev+kernel seem to work fine, I hope we can keep using them. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Making a module driver on opensc-0.11.6
On 1/22/09, Andreas Jellinghaus wrote: > the only one using the internal api is openssh, and it can be ported > to pkcs#11 - alon has done that, but it is a part of a huge change that > is unlikely to find many adopters (my personal guess - I think people > like that ssh is very easy and simple, and adding x.509 results in a quite > complex thing I guess). It does not add X.509, you can use PKCS#11 patch without X.509 patch. > I think we should discuss this scenario: > is it ok if someone uses opensc, changes it as he likes, and published the > resulting code and binaries - with one file only published as *.o (his new > card driver)? I guess that captures the spirit of the LGPL quite nicely > and is quite usable too. (but I have not checked the wording of the LGPL > to find out if that is ok, and I'm no lawyer either...) The driver is consider plugin in FSF terms, and it needs to be GPLed as well. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Making a module driver on opensc-0.11.6
Am Donnerstag 22 Januar 2009 08:08:43 schrieb Alon Bar-Lev: > On 1/22/09, Marc Rios Valles wrote: > > Hi, > > > > I have been making some test and if I don't put the two functions in > > libopensc.exports I get a segfault accessing to them... > > But these were prototyped at internal.h and internal.h was never made > public. So whoever wrote this driver used internal functions, I am not sure > this is correct. > > As far as I can see if you copy these functions and two other > functions that relay on these into your code it would work. don't copy code until you checked the license situation. my point of view is: there is not a single external driver that I'm aware off. thus we could remove the whole code for allowing external loadable drivers, as there are none, and that would simplify the code. about the internal/external situation: our long term goal should be to allow only internal tool to use the internal api, and suggest using the pkcs#11 interface to everyone. the only one using the internal api is openssh, and it can be ported to pkcs#11 - alon has done that, but it is a part of a huge change that is unlikely to find many adopters (my personal guess - I think people like that ssh is very easy and simple, and adding x.509 results in a quite complex thing I guess). I think we should discuss this scenario: is it ok if someone uses opensc, changes it as he likes, and published the resulting code and binaries - with one file only published as *.o (his new card driver)? I guess that captures the spirit of the LGPL quite nicely and is quite usable too. (but I have not checked the wording of the LGPL to find out if that is ok, and I'm no lawyer either...) Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Jeffrey Hutzelman wrote: > > PolicyKit may be useful for pcsc-lite/openct as well, to block remote > > users access to daemon. > > I'm not sure how you intend to do that, or even that it's a good idea. You can apply policy on /var/run/pcscd/pcscd.comm. (Not tested yet.) > In > fact, I'm pretty sure it's not a good idea to assume that all cards belong > to a user physically sitting at some terminal; I expect to see a usage > model in my organization that involves forwarding of reader access over an > ssh connection, in a manner analogous to how the ssh agent works. The default policy for input devices, sound, cameras, removable devices say: Never allow access for remote users. Other defaults have security implications (e. g. remote users can turn on camera and sound recording). I think that Smart Cards should use the same default policy for daemon access, otherwise remote users can authorize their requests by default. System administrator can change it. If direct access will be explicitly requested for applications using reader directly, then it should use the same policy as well. > >> HAL _can_ report these devices, and does, to pcscd. > > > > Yes, it reports them, but as unknown USB devices. > > Which is OK, because all smartcard reader devices are _not_ alike, and > pcscd needs to identify the device specifically in order to determine which > driver to use. Smart Cards readers are devices just like any others. Most of them can be identified just by reading USB ID, and even the correct driver can be identified by USB ID. -- 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 Republichttp://www.suse.cz/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Jeffrey Hutzelman wrote: > >> > HAL recognizes Smart Card readers as unknown USB devices > >> Why is that a problem? Why do you need HAL to know about smart card > >> readers? > > HAL detects correctly music players, scanners, fingerprint readers, > > UPSes (well, just only HID). Why Smart Cards should stay unknown > > devices? > This is not a use case. Please show us an actual use case. As I wrote before, I have an application, that needs direct access to the reader and I need to permit direct access to selected readers just to the local user sitting at the machine. (Yes, I know that it is bad and deprecated way to access cards, but I didn't wrote these applications.) HAL policy is the preferred way to do it in openSUSE. That is why I need to identify Smart Card readers by HAL. I don't need anything more, but when it will be done, it would be good to do it a good way to prevent changes in future. That is why I am asking here. I can imagine more use cases: Launching applications was one of examples. Another example may be: When the Class 3 reader is attached, suggest to install additional applications. Just another: When a smart token is attached during system installation, ask user, whether to configure it for encrypted devices/boot/login. Here is a short example, what I intend to do: smart_card_reader smart_card_reader smart_card.iso smart_card.class3 smart_card.ccid smart_card.ccid ccid -- 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 Republichttp://www.suse.cz/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
2009/1/22 Stanislav Brabec : > Ludovic Rousseau wrote: >> 2009/1/22 Stanislav Brabec : > >> > HAL recognizes Smart Card readers as unknown USB devices >> >> Why is that a problem? Why do you need HAL to know about smart card readers? > > HAL detects correctly music players, scanners, fingerprint readers, > UPSes (well, just only HID). Why Smart Cards should stay unknown > devices? It is just to have a pretty name in a program listing all the hardware connected to the computer? Why not. > Grating access to users physically present at the computer. > It uses standard UNIX ACL, so it can apply to both device nodes and > sockets. We already have that. What you want in fact is _denying_ access to users _not_ physically present at the computer. Why not. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Alon Bar-Lev wrote: > On 1/22/09, Stanislav Brabec wrote: > > USB peripheral cannot initiate transfer, so USB requires some type of > > polling by design. > > As far as I know and tried USB support interrupt mode, checkout the > openct trunk ccid driver. On the link level, USB interrupt mode is based on periodical re-submitting of the interrupt URB. -- 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 Republichttp://www.suse.cz/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
--On Thursday, January 22, 2009 03:54:07 PM +0100 Stanislav Brabec wrote: > Ludovic Rousseau wrote: >> 2009/1/22 Stanislav Brabec : > >> > HAL recognizes Smart Card readers as unknown USB devices >> >> Why is that a problem? Why do you need HAL to know about smart card >> readers? > > HAL detects correctly music players, scanners, fingerprint readers, > UPSes (well, just only HID). Why Smart Cards should stay unknown > devices? This is not a use case. Please show us an actual use case. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
--On Thursday, January 22, 2009 01:18:44 PM +0100 Stanislav Brabec wrote: >> I cannot >> imagine any vendor shipping policy that would allow ordinary users >> direct access to smartcard devices. > > openSUSE has to do it, at least for selected readers, otherwise users of > these applications complain. Adding a PolicyKit restriction would be a > step forward, not back. > >> > PolicyKit can ensure, that only users physically sitting at the desk >> > can use the card. >> >> Unless, as Alon points out, the user is using pcsc-lite or openct, in >> which case the daemon accesses the device, rather than the user doing >> so directly. > > PolicyKit may be useful for pcsc-lite/openct as well, to block remote > users access to daemon. I'm not sure how you intend to do that, or even that it's a good idea. In fact, I'm pretty sure it's not a good idea to assume that all cards belong to a user physically sitting at some terminal; I expect to see a usage model in my organization that involves forwarding of reader access over an ssh connection, in a manner analogous to how the ssh agent works. >> HAL _can_ report these devices, and does, to pcscd. > > Yes, it reports them, but as unknown USB devices. Which is OK, because all smartcard reader devices are _not_ alike, and pcscd needs to identify the device specifically in order to determine which driver to use. > As I wrote in other replies, I am not going to launch anything. No, but you're arguing that a use case for your proposal is to enable launching an application when a reader appears, and that's not the right time to do so. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
--On Thursday, January 22, 2009 02:57:10 PM +0200 Alon Bar-Lev wrote: > On 1/22/09, Stanislav Brabec wrote: >> Alon Bar-Lev wrote: >> > On 1/21/09, Stanislav Brabec wrote: >> Yes, udev supports it as well. But most vendors prefer HAL for this >> purpose nowadays. > > vendors? You mean Novell, right? Most of the major Linuxes, both commercial and otherwise. I believe Sun is also going down this path. >> 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. Yeah, see, that's the problem. The OP is still conflating readers and cards, probably because he's spending two much time with hardware in which the two are inseparable. The proposed HAL configuration is centered around detecting readers, which is not entirely inappropriate, but the use cases are all about doing things when a _card_ appears. Things that appear on USB busses are _not_ smartcards, _ever_. Smartcards appear _only_ in readers, which means that applications which wish to do something when a smartcard appears need only watch pcscd (or openct) and take action when a card appears. It doesn't need to know about HAL, and HAL doesn't need to know about smartcards, because there is _already_ an appropriate abstraction here. >> - 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. Yes, pcscd supports using HAL to detect hotplugging of USB devices. It also supports using libusb directly, so not wanting to use HAL is not a reason to abandon pcsc-lite. Please, come back. :-) >> 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. I have to agree here -- automatic logout needs to be tied to the particular card used to log in, if any. I perform tasks fairly frequently in which I insert a card for a short time, to authenticate to some service, and then remove it when I'm done using the service. > I am truly sorry... But I don't see the benefit. For me, it actually comes down to this. Leaving all other issues aside, the real question is what are the actual use cases that will benefit? -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
On 1/22/09, Stanislav Brabec wrote: > USB peripheral cannot initiate transfer, so USB requires some type of > polling by design. As far as I know and tried USB support interrupt mode, checkout the openct trunk ccid driver. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Ludovic Rousseau wrote: > 2009/1/22 Stanislav Brabec : > > HAL recognizes Smart Card readers as unknown USB devices > > Why is that a problem? Why do you need HAL to know about smart card readers? HAL detects correctly music players, scanners, fingerprint readers, UPSes (well, just only HID). Why Smart Cards should stay unknown devices? > I guess it is directly linked to your secondary problem. Yes. It is linked to the secondary problem and in particular to granting device access to applications that don't use pcscd. Only some of them are open source and can be modified accordingly. > But why do you need to configure PolicyKit? What is the problem > PolicyKit is trying to solve? Grating access to users physically present at the computer. It uses standard UNIX ACL, so it can apply to both device nodes and sockets. -- 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 Republichttp://www.suse.cz/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Alon Bar-Lev wrote: > On 1/22/09, Stanislav Brabec wrote: > > Alon Bar-Lev wrote: > > > This is why you have udev, right? > > Yes, udev supports it as well. But most vendors prefer HAL for this > > purpose nowadays. > vendors? You mean Novell, right? Not only Novell. GNOME desktop use HAL and vendors providing GNOME provide hal as well. Even some mobile devices use HAL (Nokia N800/810, partially also Angstrom distribution). > > 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? The main benefit: Search for devices by capabilities, not by bus where they are attached. This information may be used in any application. Several programs use HAL to show/hide systray applet, depending on device presence (Bluetooth, UPS), start user space utilities to manage particular devices etc. As none of these actions need root access, it may be easily configured. New Xorg uses HAL to detect available input devices. > For USB it is easy, no need to change anything in pcscd and openct. Definitely, it's easy. Just only several fdi files telling something about devices, no change in pcscd or openct (however libhal interface may be modified a bit to maintain device IDs just once.) > > - 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. Serial prober can support smart cards. Even without it, creating a special static file would generate smart_card_reader device event for /dev/ttyS1. > > - GUI device viewers can correctly identify device type > > Great! > But GUI can be separate. Complete separation of GUI and hardware is one of purposes of HAL. > > - Applications can easily implement device list change event listening, > > even without root access. > > This can be done via the reader frameworks... pcsc/openct. Yes, but HAL is more flexible. One code can handle autologin via smart cards and dumb USB memory cards. > > 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. A bit harder to configure, but more flexible. With udev, device match and action has to be specified at once. With udev you don't have any chance to implement negative match (e. g. This /dev/ttyS1 is not modem, but Smart Card reader. Don't allow GID modem writability to it. > > - In future it will be probably replaced by DeviceKit. > > Oh... So hal failed. Why invest more? Not completely. The idea of device infrastructure will remain there, only implementation will change. DeviceKit, DeviceKit-discs, DeviceKit-power and udev-extra packages are intended as successors of HAL. But the implementation is not yet ready. > > 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. Sorry, I meant devices = Readers. Smart card insertion detection is possible as well, but not in my plan. > > - 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... In an ideal world, where all applications use pcscd. > > - 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. My mistake. pcscd can now use hal directly. But if you don't like it, you can revert to udev helper. > 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). The dependency on hal already exists there, but you can compile without its support. HAL is only a device enumeration service. If you can live with static device configuration, most applications can exist without HAL. HAL needs about 1.2 MB of RAM. Command line utilities supporting hal exists as well (mounting of devices with user permission, device access control while logging to physical console etc.) > > 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? It's above the scope of HAL. and depends on
Re: [opensc-devel] HAL proposal for smart cards (clarification)
2009/1/22 Stanislav Brabec : > Reading the discussion, I want to clarify the original problem and > needed help: > > Primary problem: > > HAL recognizes Smart Card readers as unknown USB devices Why is that a problem? Why do you need HAL to know about smart card readers? I guess it is directly linked to your secondary problem. > Secondary problem: > > Primary problem makes impossible to define Smart Card policy to > PolicyKit. But why do you need to configure PolicyKit? What is the problem PolicyKit is trying to solve? Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
On 1/22/09, Stanislav Brabec wrote: > Alon Bar-Lev wrote: > > On 1/21/09, Stanislav Brabec 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
Re: [opensc-devel] HAL proposal for smart cards
2009/1/22 Stanislav Brabec : > Ludovic Rousseau wrote: >> PC/SC provides a method to detect reader insertion/removal. HAL is not >> needed here. > > Yes, it is. But HAL broadcasts generic device removal events. One has to > connect to pcscd to just identify, whether unknown USB device is a Smart > Card reader. If you use PC/SC API you do not need HAL. If you do not use PC/SC API I can't help. > Well, and I want to PC/SC device insertion/removal connect to HAL > instead of udev. See another mail in the thread. PC/SC device insertion/removal already uses HAL instead of udev (for USB devices). I do not know what you are talking about here. I don't know what problem Novell is trying to solve. Maybe you should try to describe the problem with details before proposing a solution. Regards -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Reading the discussion, I want to clarify the original problem and needed help: Primary problem: HAL recognizes Smart Card readers as unknown USB devices Proposal to fix: - Add a keyword for info.category (one word for device is permitted) to describe the device (other devices use for example 'sound', 'storage', 'scanner', 'biometic.fingerprint_reader' etc.) - Define keywords for info.capabilities (arbitrary number of words is possible for a single device (other devices use for example 'serial', 'input.keypad', 'block', 'camera'). Dot notation is often used to keep keywords unique. (more exact description => more chances for user software) Before proposing keywords, see http://bugs.freedesktop.org/show_bug.cgi?id=19663 We want to ensure, that these keywords don't conflict with other devices. - More is possible. For example, we can define keyword info.pcsc.driver. Needed help: Propose a smart set of keyword set to cover all Smart Card applications and related area (non-smart chip cards). Should we use keywords like 'smart_card_reader' or only 'card_reader' or even syntax like 'reader.card.iso', 'reader.card.sim', 'reader.smart_token'. What about memory card readers capable to read SIM etc. Secondary problem: Primary problem makes impossible to define Smart Card policy to PolicyKit. -- 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 Republichttp://www.suse.cz/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Jeffrey Hutzelman wrote: > > 1) There are applications, that need direct access to the reader, not > > using pcsc-lite (example: cyberjack utilities). > > And how do these devices know how to talk to readers? Do they have their > own reader drivers, separate from those included with pcsc-lite or openct? Yes, they do. Even worse, many of these solutions create a complete vendor lock. Only the underlaying OS is open sourced. > The purpose of pcscd or openct's equivalent, among other things, is to > multiplex access to smartcard devices I understand this. But it does not change the fact, that several vendors don't do it. > I cannot > imagine any vendor shipping policy that would allow ordinary users direct > access to smartcard devices. openSUSE has to do it, at least for selected readers, otherwise users of these applications complain. Adding a PolicyKit restriction would be a step forward, not back. > > PolicyKit can ensure, that only users physically sitting at the desk can > > use the card. > > Unless, as Alon points out, the user is using pcsc-lite or openct, in which > case the daemon accesses the device, rather than the user doing so directly. PolicyKit may be useful for pcsc-lite/openct as well, to block remote users access to daemon. > > 2) Up to now, HAL has no keyword for these devices and cannot report its > > presence. > > HAL _can_ report these devices, and does, to pcscd. Yes, it reports them, but as unknown USB devices. > > 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). > > If you're going to launch an application, it should happen on the basis of > the presence of a card, not of a reader. Even then, there is no reason to > assume that the presence of a card means that a particular reader should be > launched; cards may be useful for ssh, PGP, web certificates, and so on. > How would you know which application to launch? Again, I cannot imagine > any vendor actually shipping policy that did this, unless/until there is > quite a bit more work done on figuring out how to map particular cards to > particular applications, and that's not likely to pan out so well. As I wrote in other replies, I am not going to launch anything. Only identify the device as good as possible. -- 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 Republichttp://www.suse.cz/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Ludovic Rousseau wrote: > 2009/1/21 Stanislav Brabec : > > Alon Bar-Lev wrote: > >> I don't understand the motivation. > >> Why do you care if readers are accessible by all users? > > > > 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. > > The Reiner-SCT cyberJack pinpad(a) is already supported by my CCID > driver. Maybe the cyberjack utilities could be modified to use PC/SC > instead of a direct device access. > > Note: I could not find a "cyberjack utilities" software. Do you have an URL? There are utilities, that are coming with vendor Reiner-SCT cyberJack drivers: cjflash, cjgeldkarte and cyberjack. These utilities use libusb and libctapi-cyberjack directly. http://www.reiner-sct.de/support/treiber_cyberjack.php I am afraid that there are more similar third party utilities, that completely obey pcsc-lite. (e. g. proprietary POS solutions) Thinking about it again, the default policy should be: Deny to everybody except smart card daemon. If one of these utilities will be installed (by an authorized person), then direct access to the reader can be granted. > > PolicyKit can ensure, that only users physically sitting at the desk can > > use the card. > > Is that really needed? > I remember proposing such a change on the Muscle list a while ago. One > solution is to play with the permissions of the /var/run/pcscd/* files > and then restrict access to PC/SC only to the user physically sitting > at the desk. It is the purpose of PolicyKit. With proper polkit-auth arguments, denying permission after logout from physical console can happen automatically. I'll learn it more and let you know, how to do it. > > 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). > > PC/SC provides a method to detect reader insertion/removal. HAL is not > needed here. Yes, it is. But HAL broadcasts generic device removal events. One has to connect to pcscd to just identify, whether unknown USB device is a Smart Card reader. Well, and I want to PC/SC device insertion/removal connect to HAL instead of udev. See another mail in the thread. > And as Jeffrey already wrote, inserting a reader does not infer > insertion of a card in the reader. > > Why launch a banking application and not a SIM application? How to you > plan to recognise a bank card from a phone card, from a health card, > from a corporate access card, from a fidelity card, etc? It was just an example of possibilities, that the new infrastructure can bring to the user space. I want to only clean the first step: Smart Card reader feature keywords, that may be useful for authors of these applications. However I can imagine an addon, which performs card insertion detection (e. g. by polling via pcscd) and then broadcast card insertion (and card type) to the bus. HAL already provides a support for polling of particular devices: hal-disable-polling/hal-enable-polling. -- 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 Republichttp://www.suse.cz/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
Alon Bar-Lev wrote:
> On 1/21/09, Stanislav Brabec 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 Republichttp://www.suse.cz/
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards
2009/1/21 Stanislav Brabec : > Alon Bar-Lev wrote: >> I don't understand the motivation. >> Why do you care if readers are accessible by all users? > > 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. The Reiner-SCT cyberJack pinpad(a) is already supported by my CCID driver. Maybe the cyberjack utilities could be modified to use PC/SC instead of a direct device access. Note: I could not find a "cyberjack utilities" software. Do you have an URL? > PolicyKit can ensure, that only users physically sitting at the desk can > use the card. Is that really needed? I remember proposing such a change on the Muscle list a while ago. One solution is to play with the permissions of the /var/run/pcscd/* files and then restrict access to PC/SC only to the user physically sitting at the desk. > 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). PC/SC provides a method to detect reader insertion/removal. HAL is not needed here. And as Jeffrey already wrote, inserting a reader does not infer insertion of a card in the reader. Why launch a banking application and not a SIM application? How to you plan to recognise a bank card from a phone card, from a health card, from a corporate access card, from a fidelity card, etc? It looks like you are trying to do something like what Apple is doing with the smart card infrastructure: - if a CCID reader is inserted then pcscd is started - when a card is inserted each tokend is started and return with a integer value (indicating support of the card). The tokend with the highest value is used. This only works if only tokend are used by all the application. This is the case for Apple applications but not for Firefox (Firefox uses PKCS#11 and not CDSA). -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
