the uid arg to use_yp() was getting clobbered by the call to my_yp_match().
This led to a problem where a NIS user could edit root's passwd information.
Instead, treat the inability to retrieve a record from the server as a
match failure and let things take its course.
Part of the problem here is that NIS _is_ turned on, however the master
server is actually not an NIS server: it's an NIS+ server. And the client
is bound to an NIS+ replica server that's running in YP compat mode.
The code which tries to figure out of the user is local or NIS gets
confused by this.
(I'm not sure why this happens, though I suspect it may be because
the server is configured with only passwd maps instead of both passwd
and master.passwd maps. This is allowed, but I think in this case
pw_class is left NULL, hence the problem.)
Also applied similar patch to chpass/pw_yp.c just for paranoia's sake.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
enabled in /etc/master.passwd & friends. This allows the 'USER_YP_AND_LOCAL'
case to make a more sensible guess (if NIS is enabled, default to NIS,
otherwise default to local -- this is better than defaulting to NIS
all the time).
is available before trying to go hunting for a domain name. This fixes
the following problem: you have +::::::::: in /etc/master.passwd but
NIS isn't running (no ypbind, no domain name set) -- passwd and chpass
will still try to change an NIS password instead of the local one.
a master server and initialize the suser_override flag, but in a non-NIS
environment is should be smart enough to just leave the flag cleared
and return (unless forced with a command-line argument like -y).
Otherwise, it will return an NIS-related error even if NIS isn't
turned on.
Pointed out by: ache
In passwd(1):
- Gut most of yp_passwd.c and leave only a few things that aren't common
to pw_yp.c.
- Add support for -d and -h flags to select domains and NIS server hosts
to use when updating NIS passwords. This allows passwd(1) to be used
for changing NIS passwords from machines that aren't configured as
NIS clients. (This is mostly to allow passwd(1) to work on NIS master
servers that aren't configured as clients -- an NIS server need not
necessarily be configured as a client itself.)
NOTE: Realize that having the ability to specify a domain and hostname
lets you use passwd(1) (and chpass(1) too) to submit update requests
to yppasswd daemons running on remote servers in remote domains which
you may not even be bound to. For example, my machine at home is not
an NIS client of the servers on the network that I manage, yet I can
easily change my password at work using my FreeBSD box at home by doing:
'passwd -d work.net.domain -h any.nis.server.on.my.net wpaul'. (Yes,
I do use securenets at work; temporarily modified my securenets file
to give my home system access.) Some people may not be too thrilled
with this idea. Those who don't like this feature can recompile passwd(1)
and chpass(1) with -DPARANOID to restrict the use of these flags to
the superuser.
(Oh, I should be adding proper securenets support to ypserv(8) and
rpc.yppasswdd(8) over the weekend.)
- Merge in changes to allow root on the NIS master server to bypass
authentication and change any user's NIS password. (The super-user
on the NIS master already has privileges to do this, but doing it
through passwd(1) is much easier than updating the maps by hand.)
Note that passwd(1) communicates with rpc.yppasswdd(8) via a UNIX
domain socket instead of via standard RPC/IP in this case.
- Update man page.
In chpass(1):
- Fix pw_yp.c to work properly in environments where NIS client
services aren't available.
- Use realloc() instead of malloc() in copy_yp_pass() and copy_local_pass().
- Fix silly bug in copy_yp_pass(); some of the members of the passwd
structure weren't being filled in correctly. (This went unnoticed
for a while since the old yppasswdd didn't allow changes to the
fields that were being botched.)
- chpass(1) now also allows the superuser on the NIS master server to
make unrestricted changes to any user's NIS password information.
- Use UNIX domain comm channel to rpc.yppasswdd(8) when run by the
superuser on the NIS master. This allows several new things:
o superuser can update an entire master.passwd.{byname,byuid} entry
o superuser can update records in arbitrary domains using -d flag to
select a domain (before you could only change the default domain)
o superuser can _add_ records to the NIS master.passwd maps, provided
rpc.yppasswdd(8) has been started with the -a flag (to do this,
the superuser must force NIS operation by specifying the -y flag
to chpass(1) along with -a, i.e. 'chpass -y -a 'foo:::::::::')
- Back out the 'chpass -a <new password entry> breaks with NIS' fix
from the last revision and fix it properly this time. The previous
revision fixed the immediate problem but broke NIS operation in
some cases.
- In edit.c, be a little more reasonable about deciding when to
prevent the shell field from being changed.
Submitted by Charles Owens <owensc@enc.edu>, who said:
"I made a minor (one-line) modification to chpass, with regards
to whether or not it allows the changing of shells. In the 2.0.5 code,
field changing follows the settings specified in the "list" structure
defined in table.c . For the shell, though, this is ignored. A quick
look in edit.c showed me why, but I don't understand why it was written as
such. The logic was
if shell is standard shell, allow changing
I changed it to
if shell changing is allowed (per table.c) and it is a standard shell
OR if uid=0, then allow changing."
Makes sense to me.
- Update man page.
NIS (or both, or neither). Also add support for -l and -y flags to
force behavior to local or NIS. use_yp() also goes out of its way to
retrieve the correct password database information (local or NIS)
depending on what the situation since getpwent() & co. can't
necessarily be trusted in some cases.
Also document new flags in man page.
and graft it into chpass.
Chpass can now tell when it's being asked to operate on an NIS
user and it displayes the appropriate message in the editor
template ("Changing NIS information for foo"). After the changes
have been made, chpass will promte the user for his NIS password.
If the password is correct, the changes are committed to yppasswdd.
Hopefully, this should make NIS more transparent to the end user.
Note that even the superuser needs to know a user's password before
he can change any NIS information (such is the nature of yppasswdd).
Also, changes to the password field are not permitted -- that's what
yppasswd is for. (The superuser may specify a new password, but
again, he needs to know the user's original password before he can
change it.)
