Bill Paul [Tue, 22 Oct 1996 03:27:12 +0000 (03:27 +0000)]
Part 2 of fix for PR #1519. The problem here is similar to what
was going on in pwd_mkdb, except here we also have to deal with
the pw_change and pw_expire fields.
Bill Paul [Tue, 22 Oct 1996 00:41:55 +0000 (00:41 +0000)]
Modify the 'couldn't create udp handle' message so it tell you
the name of the host that couldn't be connected to. This will hopefully
make it easier to diagnose problems with certain NIS configuration
problems.
Do not backup master.passwd if pwd_mkdb returned an error. This
was to paranoid, pwd_mkdb(8) is carefully enough to not
corrupt master.passwd on failure.
Make passwords no longer echo or display. Because of this, we now also
ask for matching confirmation. I'm sure there is a clever direct-from-perl
ioctl way of putting the terminal into noecho mode, but I don't feel like
learning perl so I just used system. [yes, I'll put stty on the installation
boot floppy as necessary]
Peter Wemm [Mon, 12 Aug 1996 14:45:26 +0000 (14:45 +0000)]
Add new option to chpass: -e "expire" ; change the account expire time
from a script as if it was done in the interactive editor.
When reassembling the gecos string, trim any excess trailing commas, they
look ugly in the passwd file. :-)
Have a simple Makefile tweak to prevent mortal users from changing their
fullname. As ISP's we have seem some real bizzare stuff here..
When decoding the change/expire string, allow the month number as a
synonym for the name of the month.. (ie: 1 as well as Jan or January)
Note that using numbers means there's a chance that you can get bitten
if you're not used to the American DD-MM-YY order.
Implement incremental passwd database updates. This is done by ading a '-u'
option to pwd_mkdb and adding this option to utilities invoking it.
Further, the filling of both the secure and insecure databases has been
merged into one loop giving also a performance improvemnet.
Note that I did *not* change the adduser command. I don't read perl
(it is a write only language anyway).
The change will drastically improve performance for passwd and
friends with large passwd files. Vipw's performance won't change.
In order to do that some kind of diff should be made between the
old and new master.passwd and depending the amount of changes, an
incremental or complete update of the databases should be agreed
upon.
Bill Paul [Tue, 7 May 1996 21:05:12 +0000 (21:05 +0000)]
In use_yp(), call _yp_check() to make ultra, super-duper sure that NIS
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.
Gary Clark II [Mon, 6 May 1996 06:15:19 +0000 (06:15 +0000)]
We DON'T ship bash by default, why is it the default shell?
We also don't ship tcsh or ksh by default.
Correct these two things to make sh the default and increase csh and sh
to be higher priority.
Mike Pritchard [Thu, 11 Apr 1996 05:30:18 +0000 (05:30 +0000)]
Print some warnings if root invokes chpass and sets the
shell to one of the following:
- a non-existent file
- a non-regular file
- a file without any execute bits set
The shell is still set to whatever they entered even if the above
conditions exist (hey, it is the super user doing this after all :-),
but this might give the admin. some warning that they are about to screw
themselves and give them a chance to fix it before it is too late.
Inspired by: some new FreeBSD user on USENET who set his root shell
to a shell that doesn't exist and now can't gain access to root (don't
worry, I sent him some mail on how to recover from this).
Bill Paul [Mon, 4 Mar 1996 15:34:43 +0000 (15:34 +0000)]
Fix small bug in get_yp_master(): this function is used to look for
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.
Bill Paul [Fri, 23 Feb 1996 16:08:59 +0000 (16:08 +0000)]
Merge in changes to support the new rpc.yppasswdd(8) and fix a few bugs.
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."
Various fixes to make this work better when called from other tools.
Submitted by: Coranth Gryphon <gryphon@healer.com> & Wolfram Schneider <wosch@cs.tu-berlin.de>
Bill Paul [Sat, 2 Sep 1995 03:56:21 +0000 (03:56 +0000)]
Make use_yp() smarter about figuring out whether a user is local or
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.
Bill Paul [Sun, 13 Aug 1995 16:12:28 +0000 (16:12 +0000)]
Take the ypchfn/ypchsh stuff that was removed from passwd
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.)
Bill Paul [Sun, 13 Aug 1995 16:05:06 +0000 (16:05 +0000)]
Small NIS tweak: frob pw_error() a little so that it can say either
'NIS information unchanged' or '/etc/master.passwd unchanged'
depending on which was is being modified (conditional on -DYP).
This is to save me the trouble of writing a whole other error
routine (nis_error()?) for the upcoming changes to passwd and
chpass.
Bill Paul [Fri, 23 Jun 1995 16:24:34 +0000 (16:24 +0000)]
Somewhere along the line, somebody decided to make the 'full name' field
restricted. Am I the only one who sees the absurdity of having chfn be
a link to chpass, and then denying users permission to use chpass to
change their full names?
Of course, chpass has a much more severe bug in it, which is that it
allows users to change their password database info without first
asking them for their password. I hope to fix this at some point
so that I can merge ypchpass, ypchfn, ypchsh and chpass into one
program (password authentication is required for changing NIS data).
The problem is the returned salt, while the freebsd man pages asks that the
crypt salt string begin with a '_', no other crypt's do. If you remove the
initialization of $salt to '_' in sub salt(), everything works as advertised.
Submitted by: Charles Henrich <henrich@crh.cl.msu.edu>
o more options
o less restrictive, you can choise uid, gid ...
o invite user into some groups
o encrypted passwords with crypt
o batch mode (for instance, this works now:
$ adduser -batch jkh guest,uuadmin "Jordan K. Hubbard" passwd
see manpage for more details)
Garrett Wollman [Sat, 14 Jan 1995 23:14:25 +0000 (23:14 +0000)]
Add a `-p' option, allowing the super-user to directly set a user's
encrypted password. Kerberized `login' might use this, if I get around
to implementing the complete Allspice System behavior.
Wolfram Schneider <wosch@cs.tu-berlin.de>:
o manpage
o save configuration in /etc/adduser.conf
o send message file (/etc/adduser.message)
Submitted by: woschcs.tu-berlin.de
Update adduser to version by Wolfram Schneider. Sorry, Gary, but his
adduser is a Cadillac to your Volkswagen.. :-)
Submitted by: wosch@cs.tu-berlin.de
Maintain pw_fields, and output same to password database.
!!!!!!!!
NB
!!!!!!!!
You MUST pwd_mkdb /etc/master.passwd before attempting to use the new
libc, or things may go wrong. (I doubt anything actually /will/ go
wrong, but the actual behavior is undefined. YOU HAVE BEEN WARNED.)
The database format is, however, backwards-compatible, so old executables
will still work.