Bug 301031

Summary: Smart Card Login card detection problems
Product: [Fedora] Fedora Reporter: Jack Magne <jmagne>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: blord, rrelyea
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-27 18:44:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235704    

Description Jack Magne 2007-09-21 18:53:27 UTC
Description of problem:

We are seeing issues with smart card detection at the Smart Card Login page.
Normally when smart card login is enabled, token insertions and deletions are
quickly reflected on the smart card login screen. If the token is in, the screen
will ask for your card's password. If the token is out, it should reflect that
condition based on whether or not smart card login has been configured as required.

With the latest build, the screen is not reacting as expected to token
insertions and deletions.

Also, the screen saver is not locking the screen on removal after login on my
machine. This can be a separate bug of needed.

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

F8 test 2 upgrated to today's latest. RPM gdm-2.20.0-3.fc8

How reproducible:

Always




Steps to Reproduce:

I enabled simple smart card login with a local user. I selected "lock" on
removal and did not select it to require smart cards. F8 was installed on real
hardware, i386 version.


1.Enable smart card login, select "lock on removal" and do NOT make smart cards
required.

2. Proceed to the login screen, it will ask you to either type in your username
or plug in your smart card.

3. Plug in the smart card.

4. Note that the screen does not react.

5. Type in a bogus username and password causing the auth to fail.

6. Then the screen will react to the card and ask you to type in your card's
password.

7. Type in the password.

8. As soon as you are logged in note that the screensaver immediately brings up
the Locked screen and asks the user for their smart card's password.

9 Log out.

10. At the login screen, remove the token. Note that the screen does not react
to the missing token.

11. Type in a bogus password and note that the display refreshes to the state
where it asks for either a smart card or a unsername/password combination.



  
Actual results:

The login screen does not react properly to token insertion/removal events.





Expected results:

The login screen should react as usual to the smart card.

Additional info:

The following things were observed.

1. The token detection for ESC seemed to work ok once the user has logged in.

2. If smart card login is set to lock the screen on removal, token removals are
not invoking the lock. This could be a new bug if desired.

3. BobR thinks that the case of a root user works better than a regular user.

4.  If smart card login is set to "require" a smart card. The login screen
reacts properly to token insertion events, but not to removal events.

Comment 1 Ray Strode [halfline] 2007-09-21 19:01:27 UTC
sounds like the smart card detection code has bit rotten.  Adding to F8Target

Comment 2 Jack Magne 2007-09-27 02:07:36 UTC
I've done some investigation of the gdm side of the problem.

It appears that this is some sort of configuration issue. The following code
from "daemon/gdm.c" is not working.

static void
gdm_watch_for_security_tokens (void)
{
    GError *error;
    ScSecurityTokenMonitor *monitor;
    gchar *driver;
    GKeyFile *cfg;

    cfg = g_key_file_new ();
    if (!g_key_file_load_from_file (cfg, GDM_SECURITY_TOKENS_CONF, 0, NULL)) {
        goto out;
    }

    if (!g_key_file_get_boolean (cfg, GDM_SECURITY_TOKENS_GROUP,
GDM_SECURITY_TOKENS_KEY_ENABLED, NULL)) {

          gdm_debug ("security token support is not enabled Group:  %s Enabled
%s file
%s",GDM_SECURITY_TOKENS_GROUP,GDM_SECURITY_TOKENS_KEY_ENABLED,GDM_SECURITY_TOKENS_CONF);
          goto out;
    }

    gdm_debug ("watching for security token insertion and removal events");

    driver = g_key_file_get_string (cfg, GDM_SECURITY_TOKENS_GROUP,
GDM_SECURITY_TOKENS_KEY_DRIVER, NULL);


The line following is tripping every time in the log.

gdm_debug ("security token support is not enabled Group:  %s Enabled 

If the line "goto out" it commented out, the smart card monitoring system is
started up and appears to work.

I haven't quite figured out why this isn't working. It looks like the code to
read in that config value was different in an earlier version 
of this.

The config file in question is located in /etc/gdm/securitytokens.conf

It looks like this:

[SecurityTokens]
Enable=true
#Driver=/usr/lib/pkcs11/libcoolkeypk11.so


The log is showing the following warning I believe after trying to read in the
value:

DEBUG: Attempting to parse key string: xdmcp/Enable=false



Hopefully a similar problem is happening with the screensaver.

Comment 3 Ray Strode [halfline] 2007-09-27 14:10:27 UTC
Shouldn't that be

Enabled=true

instead of 

Enable=true?

What's the value of GDM_SECURITY_TOKENS_KEY_ENABLED ?

Comment 4 Jack Magne 2007-09-27 17:05:59 UTC
The value of GDM_SECURITY_TOKENS_KEY_ENABLED is "Enabled"


I will try that suggestion.

I've also noted that in the previous distro, the config file looks the same with
"Enable=true" as the value set in the file.

Comment 5 Ray Strode [halfline] 2007-09-27 17:36:57 UTC
turns out we've always gotten the config file wrong, so it's fallen back to the
compiled in default value (which was what the config file was supposed to have
in it).  At some point the patch got updated to use a different config file
parsing api, and the compiled in default changed.

Comment 6 Ray Strode [halfline] 2007-09-27 18:44:47 UTC
anyway, it's now failing because coolkey isn't in secmod.  Jack mentioned there
is a different bug tracking that, so i'm going to close this one RAWHIDE.