Date: Fri, 19 Jul 1996 21:19:30 -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.960719211546.11997k-100000@soda.CSUA.Berkeley.EDU> In-Reply-To: <199607200408.AAA18109@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.PTX.3.91.960719211546.11997k-100000>