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

Re: wakeup events.. thoughts?

Savochkin Andrey Vladimirovich wrote:
> > As an alternative, that carries some of the flavor of (my interpretation
> > of) your v1. What about adding two new functions to libpam:
> >
> >   pam_register_event(pamh, callback_fn, event_type, ... );
> >
> > and
> >
> >   pam_await_event(pamh, flags);
> >
> > The first would be used by modules and applications alike to tell libpam
> > about 'interesting' events to watch out for. The second is used to
> > invoke the libpam event loop. When an event is delievered, the
> > callback(s) associated with it are called and, depending upon the return
> > code for each callback, the event loop might return control to the part
> > of the program that called pam_await_event() or continue to run in the
> > event loop, waiting for the next event.
> That's close to my v1.
> The question: at which moment modules register the event handlers?

I guess when the module does something like pam_sm_authenticate or
pam_sm_setcred or ..., it can call pam_register_event() as frequently as
it likes. This way, it can register events in as complicated a way as it

> The second question: how library will make a decision if events handled by
> two or more modules happen at the same time?

I was thinking that libpam would maintain a queue of event-driven
callbacks to be dispatched. For callbacks triggered by the same event,
they would be invoked in the order they were registered. If a callback
requires that pam_await_event() returns control to the application, then
the remaining callbacks to be dispatched from the queue would be
dispatched when and if the application calls pam_await_event() again.

> I spoke about an additional pass through a special module stack for
> the registration rather than the event registration during authentication etc.
> This stack introduces some order for making a collective decision what to
> return to the application.

To some extent the pam_register_event() thing would inherit the same
ordering that the module stack has. Without some examples to discuss,
its hard for me to see if this is a good or bad thing. In general, I
would suspect that few callbacks would key off the same events, so
module/callback ordering would have a low impact on an implementation.

> In my v2 I suggested to avoid callbacks at all.
> I consider callbacks as a less natural and clear mechanism than direct calls.
> If we create an additional module stack for event processing we may avoid
> callbacks at all.  The library sleeps until an event registered by a module
> and goes through the module stack in a usual way.  Each module returns a code
> appropriate for the moment and the library compose a final code returned to
> the application.

I see this as confusing. We already have a problem with
pam_sm_authenticate vs. pam_sm_setcred. Insofar as the 'auth' module
stack control flow is dependent on module return codes, we need to keep
the pam_sm_authenticate() and pam_sm_setcred() return codes consistent -
so the admin has a hope of getting a sane configuration.

It seems to me (and I may well be overlooking something important!) that
since the admin has already created an ordered authentication stack, the
callback arrangement should naturally reflect/inherit this.

> > that fork().
> We haven't had much problems because most applications do not wait for
> children at authentication stage.  But I heard about some problems in xdm (if
> I remember correctly).
> On the event waiting stage many applications will definitely wait for
> children.
> So authentication modules _should_ register signal handlers,
> event processing modules _must_.
> So we should either
>  - implement signal handler registration in libpam, or
>  - forbid event processing modules install signal handlers,
>    force applications to install handlers without SA_RESTART,
>    and implement some hack for special EINTR handling.
> Do you see other possibilities?

I guess I'm pretty much in agreement, but to be clear, are you
suggesting that libpam override an existing signal handler for a
registered event with its own handler? If it did, we could actually
invoke the overridden handler as a side effect of evaluating our own...
My chief concern about all this is that it has implications for
thread-safeness of libpam as a whole. (A process can only have one
active signal handler at a time, independent of the number of pamh's
flying around.)

> Applications have rights to implement their own event loop.
> To avoid 'call non-blocking pam_await_event every 5 secs' approach
> we should expose desirable information collected from modules to
> applications.  Do you agree?

Could you elaborate on this?



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