passdb/pass_check.c

[James Sutherland]

On Fri, 10 Mar 2000, Peter Samuelson wrote:

> 
> [James Sutherland]
> > Obviously, if crypt() CAN return NULL, for whatever reason, then it
> > must be properly handled and checked for.
> 
> True -- unless the only time it will return NULL is for invalid input.
> Then it is sufficient to verify that it will never be given invalid
> input.  In the case of crypt(), that shouldn't be too hard.

>From a quick look at the UFC implementation for glibc, I can't see any
reason why the code would return NULL. ALL the workspace is static (for
performance reasons, I suspect). Also, there aren't really any invalid
arguments: you just pass two string pointers. Any string will do; if the
string is too short, it is padded with nulls. If the pointer you pass is
invalid, things go pear-shaped (it just calls strncpy() cast to void!) but
it still can't return NULL. The return value is ALWAYS a pointer to the
static results buffer, if the function returns at all (rather than
segfaulting).

The one exception might be if MD5 passwords are being used - I haven't
looked into that implementation yet. So, either the original problem is
due to a different implementation of crypt, or MD5 passwords.

Alex, which crypt() implementation are you using?


James.