From owner-freebsd-current Fri Jul 19 21:19:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA12160 for current-outgoing; Fri, 19 Jul 1996 21:19:46 -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 VAA12149 for ; Fri, 19 Jul 1996 21:19:44 -0700 (PDT) Received: (from richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) id VAA18094; Fri, 19 Jul 1996 21:19:32 -0700 Date: Fri, 19 Jul 1996 21:19:30 -0700 (PDT) From: Veggy Vinny To: Bill Paul cc: current@freebsd.org Subject: Re: /usr/bin/passwd and finger output In-Reply-To: <199607200408.AAA18109@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 Sat, 20 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: > > [passwd mysteriously exits with 'permission denied'] > > > > 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 > > Yes, but magically extracting the information from your brain from > such a great distance cost me dearly in terms of spells and power. > I may have to sacrifice you to the shub internet now in order to make > up for it. > > (Being a sysadmin requires you to also be part detective; nobody > ever gives you the full story in an initial problem report. Consequently, > I often interrogate people at length before I even begin any > troubleshooting. This helps me avoid situations like the following: > > user: "Help! I turned on my PC today and all my files are gone!" > me : (spend several fruitless hours going over the disk with > data recovery tools and generally pulling my hair out) > user: "Oh, by the way, I swapped the hard drive last night. Does > that matter?" > me : [CENSORED]) > > > 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? > > I don't think the behavior manifested itself 1.5 weeks ago. I think > it's been there all along and you just didn't notice it until 1.5 > weeks ago. This behavior has been inherent in passwd(1) for a long > time (well before NIS support was added, in case anyone's wondering). > It even makes a twisted kind of sense: since you logged in as user > vince this implies that you know user vince's password, not user > dennis's password. (And if you're going to cheat by (ab)using the > root account to become user dennis, you should probably just change > the password as root anyway and save a step.) > > To answer your question, there are couple of 'workarounds': > > 1) Don't su to user 'dennis': log in as user 'dennis' directly. It > should work correctly then. (This implies that you know this > user's password. Basically this means that user dennis should > not have any trouble changing his password when he logs in > as normal.) I did this a few days ago since Dennis was visiting me so he was trying to change his password and it didn't work.... I did use passwd dennis from root to do it anyways. > 2) If you must su to 'dennis,' invoke passwd with that username as > an argument: > > % passwd dennis > > Specifying a username should override the value returned by > getlogin() and then everything should agree. (Kick yourself > if you didn't think to try this until now. :) Note that if > run 'passwd dennis' as user vince, you will once again get > a 'permission denied' error, this time for the right reason. Hmmm, but if I su -l dennis from root, I thought passwd dennis isn't supposed to work. > 3) Log in as 'vince,' then su to root, then change the password for > user 'dennis' as root: > > # passwd dennis This is what I did but it was just weird that it didn't work when he logged in directly to his account and passwd returns permission denied. > As an added bonus, you'll be able to set a new password without > knowing the old one. > > 4) If you really dislike the behavior, edit local_passwd.c: find > the test where it compares uid to pw->pw_uid and comment it out. > Then recompile and reinstall passwd. (Isn't source code fun?) Oh well, it's not that big of a deal. I just remember doing a passwd from a su -l username from root as it used to work.... Vince