Date: Fri, 19 Jul 1996 22:02:10 -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: <199607200202.WAA17886@skynet.ctr.columbia.edu> In-Reply-To: <Pine.PTX.3.91.960719145805.11997N-100000@soda.CSUA.Berkeley.EDU> from "Veggy Vinny" at Jul 19, 96 03:10:29 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:
[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.
-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?199607200202.WAA17886>