Check that the -g argument is actually a number, if not report an error.
This argument is converted without checking with atoi(3) later so without this
check it converts any alpha entries into 0 meaning it deletes the group wheel
Add a regression test about it
PR: 90114
Reported by: bkoenig@cs.tu-berlin.de
MFC after: 1 week
The user was perperly adding the to different groups from "list" but was not
removed from the other groups it could have belong to.
While here add a regression test about this bug
PR: 185666
Reported by: sub.mesa@gmail.com
MFC after: 1 week
Previuosly given 'foo,bar' members, removing 'foo' would result in an
infinite loop.
PR: 191427
Submitted by: Voradesh Yenbut <yenbut cs.washington.edu>
MFC after: 1 week
is not associated with user "username". E.g., user "foo" has primary group
"wheel" and is unassociated with group "foo", yet userdel would delete the
group "foo" when deleting user "foo" (despite the fact that user "foo" is
not associated with group "foo" in any way).
Patch committed with minor style(9) changes.
PR: bin/169471
Submitted by: Alexander Pyhalov <apyhalov@gmail.com>
historic behavior (create the default base directory in pw.conf) before
I came up with a better fix for this.
Requested by: nwhitehorn
Approved by: re (kib)
When the basehome does not exist, it creates all intermediate directories as
required, which is logically equivalent to mkdir(1) with -m and -p options.
However, it modifies all intermediate directories, not just the final home
directory unlike mkdir. This problem was introduced in two revisions, i.e.,
r1.59 (SVN r167919) and r1.60 (SVN r168044).
MFC after: 1 month
The size of the username record in utmp files should not influence the
maximum username length. Right now ut_user/ut_name is big enough, so in
this case it's dead code anyway.
Remove pw_getrand() unneded now: arc4random_uniform() is stronger then
pw_getrand()'s MD5 tricks (inactive) and its active version, mixing
arc4random() bytes in one, not make things better at all.
sanity check by invoking "pwd_mkdb -C". However, if this failed it
silently returned success. Fix this so it fails the update operation
instead.
MFC after: 1 week
This makes blowfish password hashes look normal when set using
pw(8)/adduser(8). [1]
- Make it possible to have a '/' in the salt.
PR: 121146 [1]
Submitted by: Jaakko Heinonen [1]
Approved by: rwatson (mentor)
MFC after: 1 month
from a group without the need to perform the same operation by replacing
the existing list via the '-M' option. The '-M' option requires someone
to fetch the existing members with pw, deleting the undesired members from
the list and sending the altered list back to pw.
Approved by: wes (mentor)
MFC after: 5 days
the user's newly created home directory. If omitted, it's derived
from the current umask.
PR: bin/16880, bin/83253 (partially), bin/104248
MFC in: 1 month
-d option was equal to the one already saved and which caused
the pw utility to avoid updating values passed by other options
processed before the -d option in the code path.
Spotted by: Richard Caley <rjc@interactive.co.uk>
data buffering issue that corrupts files if two pw(8)'s run at the
same time as well as changing pw(8) so it uses the same locking
mechanism as PAM, vipw(8), pwd_mkdb(8), etc.
PR: bin/23501
Submitted by: Alex Kapranoff <alex (at) kapran (dot) bitmcnit (dot) bryansk (dot) su>
Approved by: rwatson (mentor)
MFC after: 5 days
or group name (mainly for the benefit of samba). This pretty much rewrites
he pw_checkname() routine, but should work exactly the same except for the
above change, and that error messages are somewhat more informative.
PR: 28733 46890
Inspired by: example patch written by Terry Lambert
Reviewed by: no objections on freebsd-arch and freebsd-current
MFC plans: no plans, but will do if people want it in stable.
This patch explains -F for usershow and groupshow. Because "groupmod
... -F" doesn't do anything, the patch also drops that from groupmod's
command line args.
PR: 35955
Submitted by: Mike DeGraw-Bertsch <mbertsch@radioactivedata.org>
mail, if configured to do so. Some sites have setups where the user's
mail is delivered to their home directory, so sending mail before is
exists didn't work.
PR: 29892
assignment of `l' in `gr_update' to the return value of snprintf. It
claimed to have fixed the case where snprintf returned -1--in fact, it
broke the entire routine. Not setting `l' here causes fileupdate() to
invariably fail with EINVAL because it does its own check to assert
that the parameter isn't -1.
