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

Re: wakeup events.. thoughts?


On Sat, Aug 21, 1999 at 11:16:02AM -0700, Andrew Morgan wrote:
> From PAM's perspective, as a point for discussion, I'd like to assert
> that the stuff of interest takes place in the #A->#B section of login,
> and that the parent code would become some sort of event loop, as
> opposed to the serial piece of code it is currently.
> The way I see it, we could evolve to something like this:
> #A
> time_to_close_session = 0;
> session_state = PAM_SESSION_UNSTARTED;
> [establishes credentials]
> do {
>     if (session_state == PAM_SESSION_NEW) {
> 	fork()
>         {CHILD: execs the user-application (a shell), eventually shell
> exits}
>         /* PARENT */
>         pam_register_event(pamh, /* register child-exit watch-event info
> */);
>     }
>     session_state = pam_wait_for_event(pamh, /* blah .. */);
>     switch (session_state) {
>     case PAM_SESSION_EXIT:
>         time_to_close_session = 1;
>         break;
>         pam_setcred(pamh, PAM_REFRESH_CRED);
>         break;
>     default:
>         ???
>     }
> } while (! time_to_close_session)
> [delete the credentials]
> #B
> Its a straw man, feel free to burn it/build on it...
> Is there a finite number of events we'd need? Is there a finite class of
> ways to register(notice) an event?

I consider credentials as something which applications possesses when they
are run by an authenticated user.  What do you think about suspension
of credentials effect or deleting the credentials when user is away from

The main loop may look like
	pid = fork();
	if (!pid) do_child();
	while (1) {
	    [resume child]
	    retval = pam_event()
	    if (retval == PAM_SESSION_EXIT)
The [reauthenticate] code should call pam_authenticate again to ask user
about a password or authenticate him via a smartcard.
pam_event() should call modules like other pam_xxx calls.
The modules may detect removing of a smartcard or trigger an event after a
period of user's inactivity.

The most interesting part is to run modules "in parallel" so that any of the
modules may trigger an event at any moment.
We've got some technical difficulty here because of a lack of means provided
by kernel.
I don't think that the real parallel (i.e. threaded execution) is good for
the case.
Well, the library can ask each module
  - if it wants to be called periodically and with what period; or
  - if it wants to be called on an event on file descriptor(s).
The library accumulates modules wishes into a single table and calls poll(2).
When poll() returns the library calls the necessary modules whether a
sensible event has happend.  So the library returns from pam_event() or
continue poll()ing.  Termination of the application can be handled via a

Best wishes

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