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

[syrius ml no-log org]

Bob Doolittle <Robert Doolittle Sun COM> writes:

>>>>>>I'd like to be able to fill the username field externaly.
[...]
>>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.

Hmm from what I've read, he's trying to do that without PAM.
(I should admit, i've also considered writing a greeter in python
that would handle my special needs :))

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

When I last answered I was considering using both.
...
duh, i'was about to say the smartcard could be the only way to login,
but in fact there're people with smartcartd and people without (yet)


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

Ok, I think I see what you mean.
Without considering the complex login (smartcard+tradionnal way) but
only the smartcard based one:
wouldn't it be as difficult to handle that kind of situation:
A user enters his card, the pam library asks for the
password/pin/whatever, the user removes his card and another user
inserts his card after him. (before the first user has completed the
authentication process)
How could this kind of situation be handled by pam libraries ?
(the password check for the 1st user has to be interrupted)

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

Hopefuly I only have to handle logons.
We have a crappy proprietary solution to allow users to log on public
windows computers with their limited smartcard (the smartcard doesn't 
contain any private key) (it's based on a crappy gina.dll that doesn't
even interact well with windows)
I'm trying to find a solution to use linux instead of windows.

My last thoughts were about to write a greeter that would handle my
special needs :)
It seems for special needs like mines, pam is not enough. And using
pam would require more hacks than just quickly hacking a greeter.

Thanks for your answer Bob.

--