Re: [gdm-list] adding a command to externaly fill the username field

[Bob Doolittle <Robert Doolittle Sun COM>]

syrius ml no-log org wrote:

> Bob Doolittle <Robert Doolittle Sun COM> writes:
>
>  
>
> > > > > I'd like to be able to fill the username field externaly.
> > > > >          
> [...]
>  
>
> > > Ok thanks for your answer.
> > > Using this given example:
> > > http://cvs.sourceforge.net/viewcvs.py/pam/Linux-PAM/modules/pam_permit/pam_permit.c?rev=1.4&view=markup
> > > and keeping nobody as "username", i would just have to replace return
> > > PAM_SUCCESS (in pam_sm_authenticate) by return PAM_IGNORE ?
> > >
> > >      
[...]

> > Eliminate the call to pam_get_user() and handling
> > of its return codes.
[...]

> Yep, And that does the trick.
> added a "auth required pam_mytest.so" for gdm and restarted it:
> It directly asked for the password.
> T
[...]

> In fact i'd love to have the features Philippe wants (as described by
> Martin here:
> http://article.gmane.org/gmane.comp.gnome.gdm.general/210)
>  
This question was answered on this list by me with
(4) subsequent responses, do you not see them? I
just tried searching for my last name and found
them. Try to read this thread to its conclusion.
I believe Phillipe was satisfied with the PAM
answer.

As for "canceling an authentication stage", what
are you trying to do, exactly? Do you have some
kind of mixed population where some people are
logging in with smartcards and some not? That's
not what Phillipe was asking for. It's trickier -
usually you want to use one kind of authentication
or another so you know what you need to do and
just do it.

If you want to handle any one of a variety of
authentication methods, you'll need *some* kind of
input event to differentiate them. I wish PAM had
a way to generate a popup message and later
asynchronously tear it down. Then you could, from
a PAM module, generate such a popup and block in
the module waiting for an event so you can tell
which authentication method to use next. But the
PAM standard doesn't have a message type for such
an event, and coding around asynch messages like
this gets ugly fast (PAM client handling would
have to become multithreaded - it's already
complex enough).

Here's how I think I'd approach this (actually I'd
try to avoid it as long as possible first - is
this really a requirement??). $DISPLAY *is* set
in the PAM context. So although it's not how PAM
was meant to be used, you *could* pop up a message
(directly from the module - not using the conv func)
that says something like "Press a key to enter
password or insert a smartcard" and then you could
poll wait on either a keyboard or smartcard event,
and then tear down your popup message and branch
into appropriate authentication logic. I think
for modularity/reusability sake I'd put each type
of logic into a separate PAM module, stack them,
and put the event detection into a module of its
own at the top of the stack. The event detection
could use pam_set_data() to pass the event type
down the stack for the subsequent modules to
check. If it's not the event type they are
designed to handle, they should just return PAM_IGNORE
immediately. Maybe so the modules could be used
independently if they don't find the event state
data they should assume they are standalone and do
what they're designed to do. This feels pretty
kludgey but it's probably the cleanest approach you
can use with PAM, if you really have a requirement
to handle multiple *alternate* forms of
authentication.

Before you turn away in disgust and go back to hacking
gdm directly - think about screensavers. Whatever auth
methods you want to use to login you probably also want
to use to unlock your screen if you've walked away for
a while. This is the primary value of PAM IMO. You can
put the same modules onto a screensaver PAM stack
as you do on gdm's stack.

-Bob