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

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



On Fri, Mar 27, 1998 at 05:45:04PM -0500, Cristian Gafton wrote:
> On Fri, 27 Mar 1998, Savochkin Andrey Vladimirovich wrote:
> 
> > 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.
> 
> How would you feel if your own libs developed for "the appplication" would
> do soemthing like that do you ?

As usual...

> 
> You can't be possibly advocating this "Oops, I just called a function from
> a library, I'd better re-open syslog, check the status of stdin, stdout
> and stderr to be sure they have the values I expect, do a seek on file
> descriptor N to be sure that the library didn't mess with it, etc."
> 
> Don't get me wrong, I am only advocating that Linux-PAM should be as
> transparent to any application as possible.
> 
> Especially when one can do syslog(LOG_DAEMON|LOG_ALERT, message) without
> the need to call openlog() to change facility. Please, somebody shoot me
> down and tell me that not having any openlog() and closelog() calls in the
> Linux-PAM modules is a wrong thing.
> 
> > I spoke about reopening syslog after PAM calls seriously.
> 
> That's a hack. Once we start doing that kind of stuff we will never stop.
> Besides, you're talking with a lazy bastard now that just happen not to
> like the idea of modifying all the pam patches in our packages to reopen
> the syslog.
> 
> > Any coder is responsible for the code that he writes.
> 
> Exactly. And I, as a coder, don't want any library to mess with my program
> state.

Could you be so kind to clarify your position more?

Let us consider an application which does:

	getpeername(sock, &addr, &addr_len);
	h = gethostbyaddr(&addr, addr_len, AF_INET);
	hostname = h->h_name;
	...
	p = getpwnam(username);
	...
	do_something(username, hostname);

PAMifying the application I rewrite it like:

	getpeername(sock, &addr, &addr_len);
	h = gethostbyaddr(&addr, addr_len, AF_INET);
	hostname = strdup(h->h_name); /* !!!!!!!! */
	...
	if (pam_start(applname, username, &conv, &pamh) != PAM_SUCCESS)
		exit_now();
	if (pam_authenticate(pamh, 0) != PAM_SUCCESS) {
		pam_end(pamh, PAM_ABORT);
		exit_now();
	}
	...
	do_something(username, hostname);

Do you consider my strdup() call as a hack?
Are you so lazy to do the same in PAM patches for Red Hat distribution?
Or will you advocate for removing all mentions of gethostbyXXX
in all PAM modules because no library should mess a program
state?
	
We have a few library calls with a brain damaged interface
(syslog, gethostbyaddr, getpwnam and so on).
I don't consider attempts to disable an usage of the calls for
PAM modules as a serious.

More and more people start to consider these broken calls as dangerous.
Glibc people already implement gethostbyaddr_r and getpwnam_r calls.
It's a time for a new interface to syslog.

The use of the new and more robust interface where it's possible is
what we should do for the PAM library and the modules.
The appropriate care for dangerous functions
is what we must do for applications.

Regards

Andrey



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