Bug 626744 - Cannot get /usr/local/lib/opensc-pkcs11.so to work with gdm-smartcard-worker.
Summary: Cannot get /usr/local/lib/opensc-pkcs11.so to work with gdm-smartcard-worker.
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gdm (Show other bugs)
(Show other bugs)
Version: 6.0
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: jmccann
QA Contact: desktop-bugs@redhat.com
URL: http://mail.gnome.org/archives/gdm-li...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-24 09:29 UTC by Patrik Martinsson
Modified: 2015-01-14 23:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-30 22:34:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The logoutput from the original smartcard-worker, compiled with opensc-pkcs11 library and another log with the output from the small hack i did just as a test. (3.67 KB, application/x-gzip)
2010-08-24 09:29 UTC, Patrik Martinsson
no flags Details

Description Patrik Martinsson 2010-08-24 09:29:49 UTC
Created attachment 440609 [details]
The logoutput from the original smartcard-worker, compiled with opensc-pkcs11 library and another log with the output from the small hack i did just as a test.

Description of problem:
I'm trying to use the opensc-pkcs11 module together with our smart-cards, I've successfully managed to use it together with pam_pkcs11. pkcs11_inspect and login works. (The login part work with gdm, but that's not the issue) 

When I insert my card the first time (or if its inserted when gdm starts) I successfully get asked about my pin, this is what you would expect. However if I remove my smart-card whiteout typing my pin I would assume that gdm detects this and throws me back to the initial login (where i can choose between smartcard & other), that's the part that doesn't work. 

I ran gdm-smart-card-worker from the terminal and attaching the log-file. 
You can see at the end of the log that gdm-smart-card-worker is expecting slot_id not be 0, which it is in my case, don't really know why (if that is normal or if my setup is wrong), I've also posted this on the opensc list to see if they have an idea. 

I added the code if (slot_id == 0) {slot_id = 1}; just to see how gdm-smart-card-worker reacted,  it didn't die and actually reported that it detected each insert/removal, however gdm didn't do anything different. (throw me back to the "initial" login screen when card is being removed etc).

I would really like to have this working. Earlier we used a module from our cardvendors together gdm (with a small hack i did myself to get it working), however due too theirs negligent and incompetent support, I would like to use opensc driver instead. And I would also like to use the official packages from rhel6 and not hack them myself. 

I'm able to test any suggestions/patches or whatever that's necessary to get this working as expected. 

Two questions directly comes to my mind, 
# 1, Smartcard driver using spec 'library=/foo/' is configured at compile time, right ? This should really be configurable at run time, shouldn't it ? Not everyone is using the libcoolkeypk11.so that is used as default, or am i wrong ? 

# 2, Wouldn't it be a good idea to remove the smart-card patch (and others too) from the huuuge multistack patch ? I'm no programmer so i don't know if there is a specific reason for why it's like this, but I find it rather hard to work with, but again, maybe there is a reason for this.  

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Compile gdm-smartcard-worker to use /usr/local/lib/opensc-pkcs11.so
2. Try to get it to work with a standard card with SetCOS on it. 
Actual results:
That gdm doesnt react on removals/insertions (except the first time)

Expected results:
That gdm reacts on every insertion/removals. 

Additional info:

Comment 2 Owen Taylor 2010-11-30 22:17:15 UTC
Hmm, I'm not sure there's really a bug report in this bug report :-) Bugzilla isn't really the best forum for getting support on getting custom-compiled code working. It's really intended for reporting defects in the code we ship and planning for updates to that code.

(Of course it's possible that defects in the code we are ship are causing your custom module not to work correctly. That would require more detailed diagnosis.)

If this is something you are still interested in, I might suggest rephrasing the bug report as a request for hardware enablement - what hardware should we support that we don't support currently? While I can't promise any particular timescale, enablement of new types of hardware is something we do frequently as part of the RHEL update cycle. And has a wider benefit than effort making a custom-compiled solution work.

Comment 3 RHEL Product and Program Management 2010-11-30 22:34:53 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.