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

Re: wakeup events.. thoughts?


On Thu, Aug 19, 1999 at 09:46:52PM -0700, Andrew Morgan wrote:
> Hi all,
> "a trip report"
> I spent the afternoon with some people from SCO, Sun and ABC (American
> Biometric Corp.) today. We talked a bit about trying to converge
> Linux-PAM and Solaris/TOG(The Open Group)-PAM, and shared some ideas
> about what's there and what's missing with PAM as is.
> An interesting problem that I'd not considered before was a need to have
> some ability for a server or a module to do something asynchronous, and
> how to code it efficiently etc..
> The examples cited as needing this were a smartcard, and a proximity
> detector. The idea being that you get to authenticate and open a session
> while your smartcard is plugged in, or you are within the vicinity of
> the proximity detector, but the moment that the card is removed, or you
> step away from the detector your session is terminated (or suspended)
> and you need to authenticate again.
> Another application is the expiration of an authorization ticket, and
> the need for a new ticket to be obtained.
> The problem is how can PAM manage the 'asynchronous wakeup event' in an
> abstracted way? Its pretty clear (to me) that we have to start
> stretching PAM a little to allow this sort of thing. And as a first
> random thought, the natural place to start from is the following
> observation that most PAMified applications are like 'login':
>    login is invoked
>    login calls pam_authenticate
>    login calls pam_open_session
>    [establishes credentials]
>    login fork()s
>       the child execs the user-application (a shell)
>       the child eventually exits
>    [delete the credentials]
>    the parent wait()s for the child to exit
>    the parent calls pam_close_session
>    the parent exits.
> The parent wait()ing, is really the parent waiting for an 'asynchronous
> event'. Along the same lines, the removal of the smartcard would be an
> event noticed by a module and/or an agent. So there seems to be a
> plausible need for something in PAM to be able notice such events and
> then to do 'the appropriate thing' as a result. This seems to be
> strongly tied to the seldom (never?) used PAM_REINITIALIZE_CRED and
> PAM_REFRESH_CRED options to the pam_setcred() function.
> Does anyone out there have any thoughts on how we might implement this?
> Want to share them?

Well, there are two points here:
 - enchancing PAM API to allow modules and applications (`login' in the case)
   exchange information for stopping and resuming sessions;
 - an implementation of stopping and resuming sessions.

#2 may be not so easy thing.  It looks much more hard than #1.
Shell and applications started from it may not
like such intervention.  For some applications there may be sections of code
where some kind of lock is held and interruption is prohibited.

So it should be stated that only certain applications will work in such
environment or some way to inform applications about session status should be

The easiest way to inform applications about session suspension is to emulate
Ctrl-Z hitting on the terminal.  Applications should have been prepared to it
and handle it properly.  The problems with this approach are
 - an additional kernel support will be probably required;
 - some applications may wish to ignore SIGTSTP.
I don't know what can be done in the later case.

Just my $0.02

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