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

Re: wakeup events.. thoughts?

Savochkin Andrey Vladimirovich wrote:
> 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
> computer?
> The main loop may look like
>         pid = fork();
>         if (!pid) do_child();
>         while (1) {
>             [establish_credentials]
>             [resume child]
>             retval = pam_event()
>             [delete_credentials]
>             if (retval == PAM_SESSION_EXIT)
>                 break;
>             [reauthenticate]
>         }

This seems like a reasonable use of an event mechanism. I'm not sure
that this loop represents all of the likely cases, but whatever gets
decided we should be able to handle this too.

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

Actually, Sun seem very keen to have their modules spawn threads and do
all sorts of things like that. They are already doing that with a
smartcard module that they have written, although the way that they
implemented stuff (with a deadline in mind) was not as ideal as they
wanted and so they will not be publishing the PAM 'extensions' that they
did, for fear of having to support them.

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

This brings up the question of what events are interesting and is there
a finite set of them that we could support and be reasonably confident
that people can do everything they are likely to want? Can we make a

  1. an event on a filedescriptor
  2. some sort of periodic event

seems like a good start. I'd like to be able to accommodate an event
like the demise of a specified child process id, and Sun seemed pretty
keen on supporting 'conditional-variables' (which seem to be a sort of
select mechanism on the contents of memory: 

You suggest that the library would ask the module about events like
this, perhaps it might be better for the module to ask libpam to watch
out for an event? In this case old modules would be unaffected by this
additional support in libpam.

> The library accumulates modules wishes into a single table and calls poll(2).

This seems like a good place to start.

> continue poll()ing.  Termination of the application can be handled via a
> signal.

This seems ok, but how this wakes up libpam (to return from pam_event())
seems problematic. The application is justified in believing it 'owns'
all of the signal handlers, so having libpam intercept one seems like
asking for confusion. Perhaps, we can use something like the conditional
variable thing to as a way to communicate that the server received a
signal that it would like to act on?



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