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.
git.ckatri.com / pw-darwin.git / log