Re: cvs commit: apr/user/unix userinfo.c

2001-03-08 Thread Jeff Trawick
[EMAIL PROTECTED] writes:

>   Allow a way to get the password from the system password database.
>   Non unix platforms will likely need a similar function.
>   Submitted by:   John Barbee <[EMAIL PROTECTED]>

How useful is this?  It certainly isn't portable.  Even some UNIX
platforms cannot have such a function.

Even with Linux, what happens with shadow passwords?  You'll get "x"
back for the password, though certainly that is not the encrypted
password.

If the goal is to validate a password, it is more portable to define a
function which does that.  Pass it a userid and password and let it
tell the caller whether or not it worked.

I think the strategy behind this needs to be reworked, and a new
function with different semantics provided instead of a function to
try to grab the password.

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...


Re: cvs commit: apr/user/unix userinfo.c

2001-03-08 Thread rbb
On 8 Mar 2001, Jeff Trawick wrote:

> [EMAIL PROTECTED] writes:
>
> >   Allow a way to get the password from the system password database.
> >   Non unix platforms will likely need a similar function.
> >   Submitted by: John Barbee <[EMAIL PROTECTED]>
>
> How useful is this?  It certainly isn't portable.  Even some UNIX
> platforms cannot have such a function.
>
> Even with Linux, what happens with shadow passwords?  You'll get "x"
> back for the password, though certainly that is not the encrypted
> password.
>
> If the goal is to validate a password, it is more portable to define a
> function which does that.  Pass it a userid and password and let it
> tell the caller whether or not it worked.
>
> I think the strategy behind this needs to be reworked, and a new
> function with different semantics provided instead of a function to
> try to grab the password.

Of course, you are correct this isn't very portable.  However, with a bit
of time and effort, and can be made portable.  John has discovered exactly
what you say in this message, and he will be working on making this much
more portable in the next few days.

Ryan

___
Ryan Bloom  [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
---



Re: cvs commit: apr/user/unix userinfo.c

2001-03-08 Thread Jeff Trawick
[EMAIL PROTECTED] writes:

> Of course, you are correct this isn't very portable.  However, with a bit
> of time and effort, and can be made portable.  John has discovered exactly
> what you say in this message, and he will be working on making this much
> more portable in the next few days.

It would be helpful to see his plans before it is committed, as I need
to add special code to validate a password on OS/390.  (John?  Care to
briefly describe your plans here?)

For now I will put in a hack to keep that file compiling on OS/390 (no
pw_passwd field).

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...


Re: cvs commit: apr/user/unix userinfo.c

2001-07-02 Thread Jeff Trawick
[EMAIL PROTECTED] writes:

> trawick 01/07/02 04:56:23
> 
>   Modified:.CHANGES
>user/unix userinfo.c
>   Log:
>   Handle the weird case where getpwnam() returns NULL but errno is zero.
>   
>   This led to a segfault on apache.org when apache did a home directory
>   lookup on an invalid user name.  This isn't cool on the part of libc,
>   but oh well.

This really sucks, but whatcha gonna do?

See /usr/local/apache/corefiles/httpd.core.20 if you're curious.
-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...


Re: cvs commit: apr/user/unix userinfo.c

2001-07-20 Thread Cliff Woolley
On 20 Jul 2001 [EMAIL PROTECTED] wrote:

> trawick 01/07/20 06:35:27
>
>   Modified:.CHANGES
>user/unix userinfo.c
>   Log:
>
>   getpwnam_safe() must be provided with the struct passwd and char
>   buffer to provide to getpwnam_r()... otherwise, the struct passwd
>   and the data pointed to by it (e.g., pw_name) are no longer valid
>   storage when getpwnam_safe() returns

Oops!  Good catch.  Thanks.  =-)

--Cliff


--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA