From owner-freebsd-current Fri Jul 19 21:12:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA11477 for current-outgoing; Fri, 19 Jul 1996 21:12:25 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA11466 for ; Fri, 19 Jul 1996 21:12:18 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id AAA18109; Sat, 20 Jul 1996 00:08:51 -0400 From: Bill Paul Message-Id: <199607200408.AAA18109@skynet.ctr.columbia.edu> Subject: Re: /usr/bin/passwd and finger output To: richardc@CSUA.Berkeley.EDU (Veggy Vinny) Date: Sat, 20 Jul 1996 00:08:50 -0400 (EDT) Cc: current@freebsd.org In-Reply-To: from "Veggy Vinny" at Jul 19, 96 08:07:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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.) 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. 3) Log in as 'vince,' then su to root, then change the password for user 'dennis' as root: # passwd dennis 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?) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================