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

Re: pam_unix_auth cleanup: NIS+ issues



On Wed, Jun 09, 1999 at 09:26:57AM -0500, Stephen Langasek wrote:
> On Wed, 9 Jun 1999, Savochkin Andrey Vladimirovich wrote:
> 
> > I wouldn't accept such changes without a deep thought.
> 
> > UID mangling may much more consequences that lie on a surface.
> > For example, seteuid(pw->pw_uid) call implies that user with uid pw->pw_uid
> > may send signals to the application calling pam_auth.
> > Different signals (SIGSTOP, SIGPIPE, SIGURG, SIGALRM) may have different
> > funny results for FTP server and other applications.
> 
> I think this question deserves some discussion then, since these seteuid()
> calls are *already present* in pam_unix_auth.  They don't work right in a

Oops... :-(

> number of situations, but they're there...  Would it be appropriate to
> disable all signal handlers (ignore signals) before changing euid and then
> restoring the handlers after the NIS+ query is done?  Is it better to move
> all to a helper binary, Ю la pam_pwdb?

I consider a helper binary as a more safe solution than any other known.
However I suspect that such a binary doesn't eliminate all possibilities for
denial of service attacks (e.g. by stopping the program).  Additional
timeouts may protect us from the obvious ones.

The implementation of the authentication should certainly invoke the helper
only if the resources aren't available directly.  Not using NIS personally I
don't want an extra overhead for a common case :-)

Best regards
					Andrey V.
					Savochkin



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