Regression: fix pw usermod -d
Mark the user has having been edited if -d option is passed to usermod and
so the request change of home directory actually happen
PR: 203052
Reported by: lenzi.sergio@gmail.com
r285396,r285398,r285401,r285403,r285405,r285406,r285408,r285409,r285411,
r285412,r285413,r285415,r285418,r285430,r285433,r285434,r285442,r285948,
r285984,r285985,r285989,r285996,r285997,r286045,r286047,r286066,r286150,
r286151,r286152,r286154,r286155,r286156,r286157,r286173,r286196,r286197,
r286198,r286199,r286200,r286201,r286202,r286203,r286204,r286210,r286211,
r286217,r286218,r286258,r286259,r286341,r286775,r286982,r286986,r286991,
r286993
Validate most pw inputs.
Rewrite the way parsing sub arguments is made to simplify code and improve
maintenability
Add -y (NIS) to userdel/usermod
pw userdel -r <rootdir> now deletes directories in the rootdir
Only parse pw.conf when needed
Reject usermod and userdel if the user concerned is not on the user database
supposed to be manipulated
- allow to create users with uid 0
- fix check duplicates logic
- fix gid policy to be in sync with uid if possible
Reported by: Jan Mikkelsen <janm@transactionware.com>
Approved by: re (marius)
r275658,r275829,r277652,r277764,r278475,r278767,r278819,r278902,r279256,
r282681,r282683,r282685,r282686,r282687,r282697,r282698,r282699,r282700,
r282709,r282712,r282713,r282716,r282718,r282719,r282720,r282721,r283809,
r283810,r283811,r283814,r283815,r283816,r283818,r283841,r283842,r283843,
r283961,r283962,r284110,r284111,r284112,r284113,r284114,r284117,r284118,
r284119,r284120,r284121,r284122,r284123,r284124,r284126,r284128,r284129,
r284130,r284133,r284135,r284137,r284139,r284140,r284148,r284149,r284392
Lots of cleanup in the pw(8) code
Add pw -R <rootdir>
Add lots of regression tests
More accurate error messages
Approved by: re (kib)
Sponsored by: gandi.net
10-stable branch, this makefile had WARNS=2, and on head the value is
still 2, but in the MFC done in r274082 it got changed to 3, causing build
failures when building with gcc. This direct commit to 10 goes back to
WARNS=2.
Add a test for bug 191427 where pw(8) will go into an infinite loop
Add some tests for modifying groups
When a group is renamed then the group has been invalidated for sure.
In that case get the group information using the new name.
Fix a regression in pw usermod -G list
The user was perperly adding the to different groups from "list" but was not
removed from the other groups it could have belong to.
Do not delete the group wheel when bad argument is passed to pw groupdel -g
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
Ensure pw userdel -u <invalid> do not try to remove root
Check the uid passed is actually a number as early as possible
Fix renaming a group via the gr_copy function
Add a regression test to pw(8) because the bug was discovered via using:
pw groupmod
PR: 193704 [1], 185666 [2], 90114 [3], 187189 [4]
Submitted by: Marc de la Gueronniere [4]
Reported by: az [1], sub.mesa@gmail.com [2], bkoenig@cs.tu-berlin.de [3],
mcdouga9@egr.msu.edu [4]
r262864: Stop pw(8) from segfaulting when given certain input (julian)
r262865: Part 2 of bug 187310 (julian)
r263114: Fix pw(8) edge-case deletion of group "username" on userdel
r267970: Fix infinite-loop during deletion of users from groups
PR: 187310, 169471, 191427
Submitted by: Voradesh Yenbut, Alexander Pyhalov, Kim Shrier
Obtained from: bug
Approved by: re (gjb)
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.
