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

Re: single incompatibility



Hi all,

> 
> Hi,
> 
> So I have been talking with Vipin of Sun/X/open XSSO (and the original
> PAM-RFC) fame and it appears that there is a single point of fundamental
> incompatibility between the Linux and XSSO versions of PAM.  It is a subtle
> point related to the behavior of the conversation functions and, if we are
> going to become completely compatible, one of us is going to have to blink. 
> The issue is one of how many responses each conversation call will return.
> 
> The documented and implemented Linux-PAM convention is to return as many
> responses as there were _prompts_.  And the undocumented (but apparently
> implemented) XSSO convention returns as many responses as there were
> messages (ie. as many responses as there are texts+errors+prompts).  On
> their side, it is conceptually simpler to program.  On our side, it makes
> for less need to worry about cleaning up the responses when only text is
> displayed in the conversation call.
> 
> Make no mistake this is something that, should we change, will create a
> significant backward compatibility problem.  Similarly, X/open feel it is
> too late for them to change to our convention.

_IF_ we decide to be compatible with XSSO we should change our documentation
and our code.

The first solution come into a mind is following.
In the PAM library we define a new PAM item named, for example, PAM_OPTIONS,
with a bitmask argument. The item is initialized in the library
by a default value meaning compatibility with the original Linux-PAM
behavior against new XSSO.
A module should check the option and determine, where the response to
a given prompt and how much responses should be free()'d.

A PAM application wanting to be compatible with XSSO practice
should do something like:

#ifdef PAM_OPTIONS
    {
        pam_options_t *options;
        retval = pam_get_item (pamh, PAM_OPTIONS, &options);
        if (retval == PAM_SUCCESS) {
            PAM_SET_OPTION (options, PAM_ALWAYS_GIVE_RESPONSE);
            retval = pam_set_item (pamh, PAM_OPTIONS, options);
            if (retval != PAM_SUCCESS) {
                /* really unexpected error */
            }
            always_give_response = 1;
        }else {
#ifdef SOMETHING_SPECIFIC_FOR_LINUX_PAM_HEADERS
            always_give_response = 0;
#else
            always_give_response = 1;
#endif
        }
    }
#else /* PAM_OPTIONS */
#ifdef SOMETHING_SPECIFIC_FOR_LINUX_PAM_HEADERS
    always_give_response = 0;
#else
    always_give_response = 1;
#endif
#endif /* PAM_OPTIONS */

pam_options_t is defined in .h file to be a set of PAM options
and PAM_SET_OPTION is a macro for setting particular option.

Later the application should determine whether to return response
consulting with a value of always_give_response.

Such construction implies that libpam and modules should
be rewritten simultaneously and applications can be rewritten
as slow :-) as desired.

The construction has following properties:
1) old applications can be compiled with both new and old headers;
2) new applications can be compiled with both new and old headers;
3) old applications being compiled with any headers
   can be run with both new and old libpam;
4) new applications being compiled with old headers
   can be run with both new and old libpam;
5) new applications being compiled with new headers
   can be run with both new and old libpam.

It seems to be possible to rewrite modules in a way allowing to plug
a new module into an old application and/or old libpam.
But I can't imagine a way to allow old module to be plugged into
a new application. We should invent a way to disable such pathological
situation.

If people in XSSO implements our PAM_OPTIONS policy (with the different
default, certainly) we achieve a full (fool?) compatibility with XSSO
of applications' and modules' sources. 

> 
> What to do.  (How) do we change?  I'd like to stimulate some discussion on
> this as I feel there are a lot of people that may be put out by this either
> way.
> 
> Comments?

Comments? :-)

					Andrey V.
					Savochkin



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