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

Re: wakeup events.. thoughts?



On Wed, Sep 01, 1999 at 09:45:31AM -0700, Andrew Morgan wrote:
> Savochkin Andrey Vladimirovich wrote:
[snip]
> > 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.

I've got your point.

I considered event awaiting as orthogonal to existing stacks.
I didn't mean to gather pam_sm_authenticate(), pam_sm_setcred(), and
pam_sm_event() in the same group.
My approach has some advantages.
 - Session suspension based on methods not related to authentication
   becomes possible.
   The example is a module checking an idle time.  It isn't related to
   authentication or account management or whatever else at all.
 - The new features are transparent and don't cause any compatibility
   problem.  Applications unaware of event waiting don't call pam_event and
   the whole process goes as usual.  The existing authentication, account
   management etc modules aren't affected too.  Only new modules of a
   new type (await_event) should know about the features.
 - Aesthetic (at my taste).  Direct calls (rather than callbacks), pluggable
   design, control of an administrator etc.
However I will not object against your approach ;-)

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

Yes.
I'm not sure if we should mess the existing calls like authenticate or not
but it seems to be necessary for pam_event_awaiting().

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

Hmm...  I've overlooked the thread-safety problem...
Shared variables between libpam instances in different threads aren't
acceptable for me.

Well, if we call the replaced signal handler it wouldn't be too bad.
If libc implementation of signal (or sigaction) guarantee atomicity
of the call signal handler installation is safe.  This way we just add
some latency to original signal handler call.
I need to think more about restoring the signal handler after the end of
libpam.

[snip]
> > 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?

I meant that if libpam collects information what modules are waiting for
it should provide applications with an interface to get this
information.  If libpam knows that modules are waiting for fds 1 (output),
3 (input), 7(input) then the application should be able to get this
information from the library.  Otherwise the application will not be able to
implement an efficient event loop.

Best wishes
		Andrey



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