Re: [gdm-list] security token monitoring architecture

[Brian Cameron <Brian Cameron Sun COM>]

Ray:

I would prefer to not clutter the GDM code with code that is specific
to a single PAM Stack implementation.  Would it be possible to make
the code more generic, so that anybody who wants to use their own
custom PAM stack could integrate?

For example, note that GDM already supports loading GTK_MODULES
for a11y purposes.  If you want this to run in-process, why not
load this as a module?

If your code to listen to smart card insertion and removal requires
additional configuration, I'd recommend using a separate configuration
file, much like the current a11y modules use.  This way the main
GDM configuration doesn't get cluttered with keys that only apply
to very specific configurations.

Does this make sense?

> So I have written code that uses NSS to load a PKCS11 driver and
> listen for smart card insertion and removal events. It's a small
> gobject that emits "security-token-inserted" and
> "security-token-removed" signals.
>
> What I'd like to do is add some configuration keys
>
> daemon/SecurityTokensEnable, daemon/SecurityTokensModule, and
> security/SecurityTokensPamStack
>
> The first key would turn on the security token monitor on startup, the
> second key would optionally load the specified pkcs11 module, and the
> third one would be an alternative pam stack to use on local displays
> when the smart card is inserted.
>
> I currently have some code in gdm.c to listen for the inserted and
> removed signals and to reset pam in those cases.  Doing it inprocess
> has a number of advantages:
>
> 1) we don't have to manage the lifecycle of another daemon (which is
> intriniscally tied to the lifecycle of the gdm daemon)

I think GTK_MODULE would be better for getting this behavior of running
in-process without cluttering the GDM code.

> 2) we don't have to communicate to gdm through its external IPC
> mechanisms, instead we can just talk to the slave directly.

Also possible via GTK_MODULE.

> 3) we can put login related smart card UI in gdmsetup.

Hmmm...  Could we also manage this via GTK_MODULES?  For example,
if gdmsetup is run with a module, then the module can add a tab?
This would be nice and avoid hacking GDM in ways specific to a
particular PAM implementation.

> Even if the security token monitor is in process, we would soley be
> using it to listen for insertion and removal events to reset PAM.  PAM
> would do all the heavy lifting.

Right.  This makes sense.  I'm just trying to think of a ways to
integrate the code so that people who want to do other kinds of
special PAM tricks can have a template to follow that works for
them also, rather than everybody who wants a specific PAM stack
asking to hack up & complicate the GDM base code.  I think making
this modular via GTK_MODULES might be a way to go?

> I could conceivably make the token monitoring code a separate daemon
> and move it to utils, but I'd like to avoid that if possible.

Yes, this is another option, but I think GTK_MODULES would do what
you want better and has the advantages of being in-process.

One slight problem with this approach is that the current code
sort of assumes that GTK_MODULES are only used for a11y purposes
so the code in gdmsetup would probably need to be made a bit
smarter to be able to turn on/off a11y without impacting other
modules that have been added for purposes like this.  I think
gdmsetup just assigns the GtkModules to the a11y modules in a
hardcoded fashion and sets it to empty when a11y is turned off.
It would probably need to check if there are other modules
and not turn off GtkModules if a11y is turned off, and likewise
not overwrite the setting if a11y is turned on, but instead
append.

Brian