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

Re: locking /etc/passwd and changing passwords



On Fri, 14 May 1999, Orlando Andico wrote:

> > If I lock /etc/passwd, only /etc/passwd, with an /etc/passwd.lock file
> > a la pwdb's __pwdb_pw_lock() function, and then run the passwd binary
> > to change a password, the passwd program reports "passwd: Critical
> > error - immediate abort". However I find that the password has been
> > changed anyway. This is on Redhat Linux 4.2 or 5.2.
> > 
> > I straced the passwd program, and it looks like even though it can't
> > lock /etc/passwd, it presses on, locks /etc/shadow, and changes the
> > password anyway. What's happening here? Is this considered a bug in
> > pwdb?
> 
> The canonical way of locking /etc/passwd and /etc/shadow (that also works
> on Solaris) would be lckpwdf()/ulckpwdf() but even Red Hat's own passwd(1)
> binary doesn't use it!! it uses its own weird locking scheme.

It's been a while since this thread was discussed, but I noticed a problem
with the lckpwdf and ulckpwdf routines in Glibc as shipped with RedHat
5.2. The following program will demonstrate the problem;

#include <stdio.h>
#include <shadow.h>
main()
{
   printf("Locking the password file\n");
   lckpwdf();
   printf("Press Return to continue");
   getchar();
   printf("Un-Locking the password file\n");
   ulckpwdf();
   printf("Press Return to continue");
   getchar();
}

Basically, ulckpwdf does not remove the lock. I originally thought this to
be a bug in the shadow suite, but tracked it down to a Glibc bug. I
submitted a bug report to RedHat but haven't heard anything about it.
Basically, there were some questions about how to properly handle
applications that might be accessing the lock at the same time.

Anyone want to take a crack at this? I created a patch against glibc that
basically issues a ulink on the lock file and that corrected the problem,
but I never took it any further..

Any suggestions would be appreciated. I realize this isn't a PAM related
issue, but it does affect any programs that use the Glibc lckpwdf
routines...

--
      President of New Age Consulting Service, Inc.  Cleveland Ohio
           http://www.nacs.net   info@nacs.net   (216)-619-2000
         An athletic supporter of the Cleveland Linux User Group
                        http://cleveland.lug.net



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