Date: Sat, 20 Jul 1996 00:08:50 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: richardc@CSUA.Berkeley.EDU (Veggy Vinny) Cc: current@freebsd.org Subject: Re: /usr/bin/passwd and finger output Message-ID: <199607200408.AAA18109@skynet.ctr.columbia.edu> In-Reply-To: <Pine.PTX.3.91.960719200611.11997d-100000@soda.CSUA.Berkeley.EDU> from "Veggy Vinny" at Jul 19, 96 08:07:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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."
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607200408.AAA18109>