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

Re: Is this legitimate? (Module/application interaction.)



Re: passing arbitrary data between module and application.

What about adding a PAM_REGISTER item that would provide a callback hook
to the application (similar to the PAM_CONV item) and could be used to
generically extend the PAM items.

The PAM_REGISTER item would be a pointer to a struct like this:

  struct pam_register {
      int (*set_item)(const char *name, int length, void *data);
      int (*get_item)(const char *name, int &length_p, void **data);
      int (*delete_item)(const char *name);
      void *appregister_ptr;
  };

The use of appregister_ptr would be basically equivalent to the
appdata_ptr use in the conversation function..  All libpam needs to know
about this type is that it can be treated as a block of memory that it
can malloc+copy and then, when pam_end is called, it can be
wiped+free()d.  That's the kind of low overhead I'm happy with for
libpam.

At compile time, an application could have stuff like this, which would
make this extension available to modules supported drectly by the
application.

#ifdef PAM_REGISTER
  retval = pam_set_item(pamh, PAM_REGISTER, &local_register_struct);
  if (retval != PAM_SUCCESS) {
     /* Mmm.  we were compiled with a PAM that supported PAM_REGISTER,
        but are currently linked with one that doesn't.. Oh well,
        no register support for modules then. */
  }
#endif

Modules could be compiled with code like this:

#ifdef PAM_REGISTER
  struct pam_register *register_p = NULL;
  retval = pam_get_item(pamh, PAM_REGISTER, &register_p);

  if (retval == PAM_SUCCESS && register_s) {
     /* the app has support, so make use of it... */
  } else {
     /* need to deny user some flexibility, or fall
        back on an environment var or something else */
  }
#endif

I like this better than making every module responsible for maintaining
the chain of session_data items.  Such things are frequently a cause of
bugs and in general will lead to significant code duplication within the
modules.  They also contribute to the possibility that one buggy module
can bring down the rest.

Does anyone have any objection to this new PAM_REGISTER item?  Or
perhaps a better suggestion?  (I'm not convinced I like the PAM_REGISTER
name, if this extension is something people think it a good one, feel
free to suggest a better label for it.)

Cheers

Andrew

Allan Bjorklund wrote:
> > The pam_[sg]et_item()s are the other obvious interface..  If someone
> > could come up with a PAM_SESSION_INFO item-type that had sufficiently
> > low maintenance cost but a high extensibility, I can think of a
> > number
> > of things that might benefit from it.
> 
>   Let's see...
> 
>     Application places a structure in place with a name tag being the
> first element.  Module checks this name tag, if it recognizes it, it can
> fill it in, otherwise ignore.  The application would be responsible for
> clean up.
> 
>   Or the structure could be like this:
> 
>       struct session_data {
>                char                *name_tag;
>                struct session_data *next;
>                int                 (*cleanup)(clean up parameters);
>                void                *session_data_ptr;
>       };
>



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