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

Re: wakeup events.. thoughts?



Savochkin Andrey Vladimirovich wrote:
> [fd-selects and timeouts are easy, signals(exiting children) are hard.]

Yes.

> How to pass the event information is a not very important question for me.
> The module may set the information by a special library call before returning
> PAM_WAIT_EVENT.  Or the library may ask the module about this information by
> a special call seeing PAM_WAIT_EVENT.

Ouch, you are a little ahead of me here! This complicates matters a lot.
It seems to capture some more general aspect of
PAM_CONV_AGAIN/PAM_INCOMPLETE thing. In so far as the module has not
completed but, for whatever reason, it wants to hand back control until
an event occurs. Do you mean this could be before the
session_open+fork()?

My model up to this point had been: the serving application is basically
waiting for the child 'service' to exit, and that we were attempting to
provide hooks for a module to preempt this exit event with some
authentication related event and optionally terminate the
session/reauthenticate/refresh whatever.

> [for signals.. EINTR + ... ]
> signal i.e. making the signals "broadcast".  This solution raises other set
> of problems:
>  - existing modules and applications may require to be modified to use the
>    feature;
>  - modules and applications should be prepared that the signal handler is
>    called when nothing (related to the module or application) has happened.
>    For instance, SIGCHLD handler should be ready to an occasion that the
>    child hasn't really finished.
> Well, it's really a difficult problem.

Agreed.

> [pthreads, xxx-threads, which ones? Portability, inefficiency and bad
>  experiences... too early to commit to one or other flavor under Linux.]

I am inclined to agree with this analysis. Sun on the other hand are as
happy as clams with posix-threads, and are keenly embedding them in
their modules... What I'd like to see is us contribute to an API that we
can support/maintain given Linux as-is and they can support too. I'd
like it to not preclude the use of (any flavor) of threads, so they
don't reject the API, and yet be simple enough that without libpam
knowing about threads, a careful Linux module/app programmer could use
it with clone() or whatever and get their job done.

> The idea of conditional variables doesn't look good to me at the moment.
> Waiting on a variable will require either
>  - CPU consuming busy loop (very bad)
>  - spawning threads (not so good)
>  - or use existing implementation which implements one of the methods above.

My impression was that Solaris has some sort of kernel support for this
'wake on memory write'. I could be wrong.

> etc).  So threads in a library like libpam looks impractical at this stage.

I certainly do not think we need to have threads spawned and running in
parallel within libpam any time soon, but I would like to think that
modules and applications could have them - provided they abide by the
one pamh per thread that calls into libpam rule.

Here is a list of event_types that we've discussed:

 PAM_EVENT_TIME_RELATIVE (*) [RELATIVE and ABSOLUTE?]
 PAM_EVENT_FILDES_SELECT (*) [Do we need read/write specificity?]
 PAM_EVENT_CHILD_EXIT        [More generally, handle any signal]
 PAM_EVENT_MEMORY_WRITE      [The essence of conditional variables]

The (*) ones are supported by select()/poll(). The CHILD_EXIT one
will/may generate a signal, and is probably limited to an
'application-specific' event and not something we want a module to be
doing much of. The MEMORY_WRITE event is something we do not have kernel
support for, but which might be usable for modules trying to manage
threads (of whatever flavor).

_If_ we had some efficient way of supporting the last one, we could
obviate the need for the CHILD_EXIT event. Namely, we'd require that
whoever launched the child needs to handle its exit and then do a write
to some pre-registered memory location (all done within a signal_handler
perhaps?).

The flow of control being that the application has called
pam_await_event(), the child dies, the application receives a signal
who's handler writes to a memory location announcing that this
PAM-relevant event has occurred and then the signal handler exits,
returns control to pam_await_event(), which sees that the memory is
written, and takes the appropriate action for that event.

All that does start with an _if_ though. Without kernel support, it
looks like some sort of busy-wait is the only way we could do this. We
could do a little better than blindly hogging the CPU by doing a
semi-busy-wait within libpam with say a one second granularity, and just
have a little delay picking up the phone when some memory is altered.
(In the case of the child dying, our select/poll call would return early
so we'd not be that slow to notice this type of event.)

In the case of smart cards, the hardware/drivers are not always created
with select() type of symantics in mind. My limited experience so far is
that you need to probe them frequently to establish their current state.

Finally, we should also support applications with their own event loop,
we could have a non-blocking way of invoking pam_await_timer(), that
returns immediately if there are no events pending.

Comments?

Cheers

Andrew



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