functionality when nothing had actually changed; -d changes would
not set the 'something had changed flag'. Actually test for a
change in homedir.
PR: bin/19649
a full reindex in this case to remove the old record. #ifdef -u capability
since this is available on FreeBSD only.
PR: bin/16418
Problem pointed out by: Masachika ISHIZUKA <ishizuka@ish.org>
pw(8) was calling pwd_mkdb -u oldusername instead of newusername, so
the update appears to have failed until the next full pwd_mkdb
syncronization.
PR: bin/16418
happened as it was working around problems elsewhere (ie: binutils/ld
not doing the right thing according to the ELF design). libcrypt has
been adjusted to not need the runtime -lmd. It's still not quite right
(ld is supposed to work damnit) but at least it doesn't impact all the
users of libcrypt in Marcel's cross-build model.
like "pw usermod <name> -m" to work for non-local NIS users; since no attempt
is made to update the password entry, the home directory will be created and
populated as expected without error.
instead of a boolean. This replicated through he front-end sub-functions
relating to add, delete, modify entries in passwd & group files
Errno is now preserved so output of errc()/warnc() will be less obfuscated
by subsequent errors when reporting the problem.
Add more intelligent error handling when attempting to modify/delete NIS
entries with no corresponding local database entry.
[MFC to stable in a couple of weeks to keep both in sync]
The char that the random letters and numbers are being pulled from is
ended with a '\0'. Using sizeof() includes this '\0' in the 'pool' of
possible characters. This patch decrements by one the size so we don't
accidently end the new password prematurly.
and terminate it. This patch ensures passwords will be the correct length of 8,
which is what is implied in the source (but not reflected in the man page).
PR: bin/7817
Reviewed by: Alfred Perlstein <bright@hotjobs.com>
Submitted by: Hiroshi Nishikawa <nis@pluto.dti.ne.jp>
consider it a exit failure if it doesn't work. This means that root
processes can safely get the lock, but normal processes can still use
the 'pw' utility to get information (which may change out from under
them.)
from PR/6787, but allow non-root users to use pw to get password
information. However, this should be safe since the fixes for
disallowing multiple instances from modifying the DB are still intact.
Bug noted by: dima@best.net (Dima Ruban)
run at the same time.
Notes:
The fileupdate function is still somewhat broken. Instead of
returning a failure code if it can't modify the original file it
renames the .new file and continues as though nothing is wrong.
This will cause the lock on the original file to be lost and could
lead to a similar race condition. I left that portion of the code
alone since I feel that the maintainer of the code would have a
better concept of how he wants to handle errors in that function
than I do.
PR: bin/6787
Submitted by: Craig Spannring <cts@internetcds.com>
