Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Jul 1996 20:07:09 -0700 (PDT)
From:      Veggy Vinny <richardc@CSUA.Berkeley.EDU>
To:        Bill Paul <wpaul@skynet.ctr.columbia.edu>
Cc:        current@freebsd.org
Subject:   Re: /usr/bin/passwd and finger output
Message-ID:  <Pine.PTX.3.91.960719200611.11997d-100000@soda.CSUA.Berkeley.EDU>
In-Reply-To: <199607200202.WAA17886@skynet.ctr.columbia.edu>

next in thread | previous in thread | raw e-mail | index | archive | help


On Fri, 19 Jul 1996, Bill Paul wrote:

> Of all the gin joints in all the towns in all the world, Veggy Vinny had 
> to walk into mine and say:
> 
> [chop] 
> > > > dennis@mercury [1:45pm][~] >> passwd
> > > > passwd: Permission denied
> > > > dennis@mercury [1:45pm][~] >> dir /usr/bin/passwd
> > > > -r-sr-xr-x  2 root  bin  32768 Jul 19 12:45 /usr/bin/passwd
> > > > dennis@mercury [1:45pm][~] >>
> > > 
> > > How about trying 'which passwd' and seeing what it returns? How
> > > about trying to run /usr/bin/passwd explicitly (with the full path)?
> > > You sure you don't have a /usr/local/bin/passwd or a cutsey alias
> > > hidden away somewhere?
> > 
> > 	yep, because this is what I got:
> > 
> > dennis@mercury [2:57pm][~] >> which passwd
> > /usr/bin/passwd
> > dennis@mercury [2:57pm][~] >> dir /usr/local/bin/passwd
> > colorls: /usr/local/bin/passwd: No such file or directory
> > dennis@mercury [2:58pm][~] >>
> 
> How about echo $USER?
> 
> Okay, after playing around a bit, I could only find set of circumstances
> where passwd(1) would say 'Permission denied' persistently. Unfortunately,
> I don't think this is the cause of your problem. Here's the deal:
> 
> - When passwd starts up, it does a getlogin() in order to determine
>   the username of the user that invoked the command. (This can be
>   overriden by the superuser, who is allowed to specify a username
>   on the command line.)
> 
> - Since passwd is compiled with YP support, it later calls use_yp()
>   with the name of the user to do an exhaustive check to figure out
>   if the user is local, YP or both. This also fills in a passwd struct
>   called local_passwd.
> 
> - Since the user is local, local_passwd() is called. The first thing
>   local_passwd() does it call getuid(), and then it compares the
>   UID that getuid() returns against the UID in the local_password
>   struct.
> 
> Now here's the problem. Let's say I log in as user wpaul. If I then
> run a program that calls getlogin(), the result will be "wpaul".
> Now let's say I su to some other user. If I again run a program
> that calls getlogin(), the result will still be "wpaul". So here's
> what happens with passwd:
> 
> - I log in as wpaul and su to user foo.
> 
> - passwd calls getlogin() and gets back 'wpaul'. use_yp() fills in
>   local_password with the info for user 'wpaul'.
> 
> - local_passwd() calls getuid() and it gets back the UID for user
>   'foo'.
> 
> - local_passwd then compares the UID returned by getuid() and
>   local_password.pw_uid and sees that they don't match (getuid()
>   returns the UID for user 'foo' while local_password.pw_uid
>   contains the UID of user 'wpaul').
> 
> - Since the UIDs don't match, and the user is not root, passwd
>   exits with EACCES ("permission denied").
> 
> I'm not sure if this is the cause of your problem or not. If you
> actually log in as a user rather than using su, passwd works correctly
> because getlogin() and getuid() agree.
>  
> > 	Hmmm, this happened after the code change to chpass and passwd for
> > the sources a week or so ago.
> 
> Hurm. Not sure if that's related. I really need to test this on
> a -current box.

	You're right about this one except I logged in as user vince then 
su to root so then I su -l dennis and then did the passwd, this used to 
work in -current as of 1.5 weeks ago but is there anyway around this?

Vince





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.PTX.3.91.960719200611.11997d-100000>