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



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 ?
("nobody" would be used as username and the next pam module would take care of the password check)
Sorry if the question "sounds" silly, the pam module writer guide
doesn't look straightforward to me. :)

Yes it's too bad the interface is so arcane.  Cribbing
code like this is a good approach.

Eliminate the call to pam_get_user() and handling
of its return codes.  That's the call that
actually is causing gdm to prompt you to enter
your user name (I hope - at least it should be
assuming gdm is using PAM correctly - if it isn't
that'll need to be fixed).  Easy experiment at
least, right?

Note that many PAM modules will call
pam_get_user().  As long as PAM_USER is set in a
previous module (or by the client i.e. gdm), this
call turns into a NOP - it only prompts when
PAM_USER isn't yet known, and PAM items like this
are inherited from previous PAM modules on the
stack in /etc/pam.d or pam.conf (you'll need to
read the man page for pam.conf to see how to add
your module to the stack).

(sorry, this is the last off-topic mail to the gdm list)

You're certainly not the first person with such a
question.  People's first gut reaction is to dive
into gdm and change it.  I'd like to encourage
people to use pluggable frameworks like PAM where
possible.  It's more modular, more reusable,
easier to develop and debug, and eliminates the
distro dependencies making it easier for you to
deliver your solution.  Also by not constantly
tweaking gdm we have a more stable display
manager in the long run.

Typically I'd write a simple PAM client to
initially test my module.  That
makes testing really easy because you can do
it in a simple shell environment, use debuggers
easily and all that good stuff, before trying it
with gdm.  Maybe your code will be so trivial
this isn't necessary.

-Bob

P.S. I haven't a clue what that bizarre structure
definition at the bottom of the module you linked
to is trying to do.  I don't believe it is required.
Looks like something left over from somebody's
test environment.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]