From owner-freebsd-current Fri Jul 19 20:06:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA06332 for current-outgoing; Fri, 19 Jul 1996 20:06:53 -0700 (PDT) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA06326 for ; Fri, 19 Jul 1996 20:06:50 -0700 (PDT) Received: (from richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) id UAA15049; Fri, 19 Jul 1996 20:07:11 -0700 Date: Fri, 19 Jul 1996 20:07:09 -0700 (PDT) From: Veggy Vinny To: Bill Paul cc: current@freebsd.org Subject: Re: /usr/bin/passwd and finger output In-Reply-To: <199607200202.WAA17886@skynet.ctr.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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