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

An interference between PAM and other libraries [was: Linux-PAM and syslog]

I want to raise a more general question than the right way to use syslog
in PAM modules.

> -----Forwarded message from Cristian Gafton <gafton@redhat.com>-----
> On Thu, 26 Mar 1998, Savochkin Andrey Vladimirovich wrote:
> > The particular question about syslog that Cristian raised isn't very difficult.
> > The correct and natural solution is to patch application that uses both PAM
> > and syslog to reopen syslog after PAM calls.
> This is completely dump and I really hope you are not serious. Simply
> because sometimes it is not possible and that we promised that using PAM
> would mean replacing getpwnam()/crypt()/strcmp() calls with a simple call
> to pam_auth functions.
> I advocate removal of all the openlog and closelog calls from pam modules.
> The pam modules will log under application's name and facility (whihc
> makes a *whole* lot more of sense).
> > PAM modules are allowed to log what they want and with facility and priority
> > they wanted.
> No kidding, said who ? I don't find any trace of this bill of rights in
> the PAM specs.

I refered to 


which states:

   In general, writers of authorization-granting applications should
   assume that each module is likely to call any or all `libc' functions.
   For `libc' functions that return pointers to static/dynamically
   allocated structures (ie. the library allocates the memory and the
   user is not expected to `free()' it) any module call to this function
   is likely to corrupt a pointer previously obtained by the application.
   The application programmer should either re-call such a `libc'
   function after a call to the Linux-PAM library, or copy the structure
   contents to some safe area of memory before passing control to the
   Linux-PAM library.

Reading the state first time I was under impression that
it restricts a library caller too much.
Now I consider the state as a natural and only possible.

We just found one of dangerous libc calls -- syslog.
Right now I could add the next ones -- gethostbyXXX.
The assumption that the static libc data used in gethostbyname
call is preserved accross calls to PAM or any other library
is an unreasonable and dangerous one.

How to find the list of all dangerous calls is a _real_ question.

I think that we should act according to a general robustness principle.
Being PAM module developer we should avoid calls known as dangerous
and use more robust variants (suggested pam_misc_syslog, gethostbyname_r, ...)
when it's possible.
Being an application developer we should assume the worst behavior
from PAM library and modules and reopen syslog and do other things
which protect our application from unexpected behavior of other libraries.

> And using common sense, if after calling a function in a library I have to
> take care of some completely unrelated problems (like syslog), I'll say
> "no, thanks" to that library...

I spoke about reopening syslog after PAM calls seriously.
I said and will say "thanks" to Linux-PAM library.

Any coder is responsible for the code that he writes.
He must think what he is doing when he codes and considers
all direct and indirect consequences of adding a new code to an application.

"It's easy to do" can't be an argument for advocating the use of PAM
in applications.
"It's a Right Way To Do" is an argument.



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