RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gdm
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: jmccann
QA Contact: desktop-bugs@redhat.com
URL: http://mail.gnome.org/archives/gdm-li...
Whiteboard:
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2010-11-30 22:34:53 UTC
Target Upstream Version:
Embargoed:


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):
gdm-2.30.4-5 

How reproducible:
Always. 

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. 
3.
  
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 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.