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

Savochkin Andrey Vladimirovich <saw@msu.ru> writes:

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

  The modules that use these potentially state-destroying calls should take
extreme care to restore the old state upon exit if at all possible.  With
gethostbyXXX this would be impossible though - but the pam modules could
just as easily use a reentrant interface (the gethostbyXXX_r calls, etc).

  I would argue that the two snippets of code above differ significantly.
When you do a getpwnam() call, you do all the authentication checking
yourself via crypt() and memcmp() typically, but when you use the more
advanced API like pam_*, then you would be best off restructuring the
program a little.

  Anyway, I would say the program above should do the authentication before
the reverse DNS lookup, since that can be a potentially long process, and
you would have to sit through it and then realize the user failed to
authenticate. :)

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

  Things like getXXXbyXXX have been 'broken' for a long time and people are 
generally used to being cautious about copying the returned data.  But for
something like syslog that is supposed to be for the application (quoth the 
manpage: openlog()  opens  a  connection to the system logger for a
program), I think it is asking a bit much of the application developer to
work around pam in that way.

-Bill P.

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