Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 59660 invoked by uid 500); 8 Mar 2001 11:25:52 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 59645 invoked from network); 8 Mar 2001 11:25:50 -0000 X-Authentication-Warning: adsl-77-241-65.rdu.bellsouth.net: trawick set sender to trawickj@bellsouth.net using -f Sender: trawick@bellsouth.net To: dev@apr.apache.org Subject: Re: cvs commit: apr/user/unix userinfo.c References: <20010308003539.99292.qmail@apache.org> From: Jeff Trawick Date: 08 Mar 2001 06:24:52 -0500 In-Reply-To: <20010308003539.99292.qmail@apache.org> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N rbb@apache.org 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 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 | trawickj@bellsouth.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...