passdb/pass_check.c

James Sutherland jas88 at cam.ac.uk
Fri Mar 10 17:06:54 GMT 2000


On Fri, 10 Mar 2000, Steve Langasek wrote:

> On Fri, 10 Mar 2000, James Sutherland wrote:
> 
> > >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.
> 
> I have seen NULL returned from crypt() when using glibc's md5 implementation
> (glibc 2.1).
> 
> Should this be considered a bug, or is this allowed by the relevant specs? (Of
> course, I don't think POSIX ever said anything about using crypt() for MD5..)
> Given that there are some implementations that will return NULL, however
> broken they are, it seems advisable to always check the return value before
> proceeding, IMHO.

Agreed. Essentially, at present crypt() CAN return NULL to us under some
circumstances, so we MUST handle this gracefully. Either that, or provide
our own crypt() which does not return NULL under any circumstances?

(UFC is LGPLed; including a copy shouldn't be a problem legally, but it
does seem like rather a cumbersome approach.)

I think, though, we'll just have to start checking for NULL returns from
crypt()...


James.



More information about the samba-technical mailing list