[15799] in Kerberos_V5_Development
Re: a suggestion for improving pkinit preauth plugin token choosing
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Wed May 12 11:57:49 2010
Date: Wed, 12 May 2010 10:57:22 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: "Douglas E. Engert" <deengert@anl.gov>
Message-ID: <20100512155722.GA9429@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4BEAC26B.6040000@anl.gov>
Cc: "Henry B. Hotz" <hotz@jpl.nasa.gov>, Sam Hartman <hartmans@mit.edu>,
"krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Wed, May 12, 2010 at 09:59:55AM -0500, Douglas E. Engert wrote:
> Its the current PAM architecture that is weak. Pam needs a better front
> end to give the user some choices, and a better way to propagate those
> choices to the individual PAM modules.
I fully agree that PAM's conversation concept is busted. Here's a
partial list of problems with it:
- it's clearly designed for a tty world, so...
- ...it has no concept of "OK" and "cancel" buttons, or any other GUI
contructs (forget radio buttons, checkboxes, ...)
- prompts cannot be canceled asynchronously: the user *must* hit ENTER
(or click OK), so...
- ...there's no way to make an "insert smartcard" prompt go away when
C_WaitForSlotEvent() indicates that a token is available;
- there's no indication to the application as to what kind of item or
action is being prompted for;
- there's no direct way for the app to indicate that the conversation
context is a GUI context or a tty context (not setting PAM_TTY
doesn't work for this; think of ssh);
- there's no extensibility; adding GUI support will require massive
re-writing of PAM application and module code;
I could probably go on.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
