When removing a user's home directory, if the directory is a ZFS
dataset, it cannot be removed. If the directory has been emptied,
use "zfs destroy" to destroy it. This complements the automatic
dataset creation in adduser. Note that datasets within the directory
and snapshots are not handled, as the complete path is not constructed.
While here, add waitpid() calls to rmat() and pw_user_del().
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D45348
Rename `M_PRINT` and `M_UPDATE` to `M_SHOW` and `M_MODIFY` to match the
names of the commands they represent. No functional change intended.
MFC after: 3 days
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D45096
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
Fix the following problem:
1. A nonexistent user, someuser, is added to /etc/group as
someuser:*:12345:someuser.
2. someuser is then created with the default login group.
A second group entry for someuser will be created.
someuser:*:12345:someuser
someuser:*:12346:
With this fix, the existing group entry will be used.
PR: 238995
Reviewed by: bapt, jrm
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41057
Fix the following problem:
1. A nonexistent user, someuser, is added to somegroup in /etc/group.
2. someuser is then created with membership in somegroup.
The entry for somegroup in /etc/group will then contain
somegroup:*:12345:someuser,someuser
With this fix, the entry will be
somegroup:*:12345:someuser
PR: 238995
Reviewed by: bapt, jrm
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41076
When adding a user, pw will create the path to the home directory
if needed. However, if creating a path with just one component,
i.e. that appears to be in the root directory, pw would create the
directory in /usr, and create a symlink from the root directory.
Most commonly, this meant that the default of /home/$user would turn
into /usr/home/$user. This was added in a self-described kludge 26
years ago. It made (some) sense when root was generally a small
partition, with most of the space in /usr. However, the default is
now one large partition. /home really doesn't belong under /usr,
and anyone who wants to use /usr/home can specify it explicitly.
Remove the kludge to move /home under /usr and create the symlink,
and just use the specified path. Note that this operation was
done only on the first invocation for a path, and this happened most
commonly when adding a user during the install.
Modify the test that checked for the creation of the symlink to
verify that the symlink is *not* made, but rather a directory.
Add a test that intermediate directories are still created.
Reviewed by: rgrimes, bapt
Differential Revision: https://reviews.freebsd.org/D40085
The pw_checkname function forgot to include a ';'
when checking usernames, causing shell commands
to be executed when a username with a ';' is deleted.
PR: 271427
MFC After: 3 days
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Make 'line' static to move it to .bss instead as that pattern is used
elsewhere in pw(8) (e.g. the static buffer in pw_pwcrypt).
Reported by: GCC -Wdangling-pointer
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D37534
The command "pw usermod nobody -Nw random" (or useradd)
generates random password and prints it in encrypted form
but skips choosen random string that makes not much sense
and contradicts the manual page pw.8
Fix it by showing random password in plain text with -N and
without it equally. Add yet another example of how to generate
pw-style random password.
MFC after: 2 weeks
This allows building a container image with enough functionality for
downloading and installing packages without having to include the
utilities package.
Reviewed by: manu
MFC after: 2 weeks
Arguments passed to flags like -d and -k had ambiguous names like "dir".
Change that to more descriptive names like "homedir".
Also, clarify that -u min,max is for UIDs and -i min,max for GIDs.
MFC after: 1 week
Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas and introduced a WARNS=7 and wanted to try lifting the default to
that.
Drop most of them; there is one in the blake2 kernel module, but I suspect
it should be dropped -- the default WARNS in the rest of the build doesn't
currently apply to kernel modules, and I haven't put too much thought into
whether it makes sense to make it so.
The caller-supplied pointer is unconditionally dereferenced at the
beginning of the function, so there is no point in comparing it with
NULL thereafter.
Reported by: Coverity
MFC after: 1 week
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
When deleting a user, if its home directory does not belong to it, it should
not be removed. This is the promise that the manpage makes, the tool should
ensure that it respects that promise.
Add a regression test about it
PR: 244967
Submitted by: Eric Hanneken <eric@erichanneken.com>
MFC after: 3 days
Instead of using pw to modify group membership, users often edit
/etc/group by hand, which is discouraged. Provide an example of
adding a user to the wheel group, which is a common use case.
I'm using a different user here as in the previous example as that
deleted the user (although the examples don't necessarily have to
be followed in order).
Reviewed by: rgrimes,0mp
Approved by: 0mp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D19123
it. Drop the now unused _PATH_PW_CONF definition. [1]
While here, change the last remaining hardcoded "/etc" to _PATH_PWD.
Noted by: glebius [1]
Reviewed by: eugen
Approved by: re (gjb), kib (mentor)
Differential Revision: https://reviews.freebsd.org/D17575
explicitly specified. -V path is already used to determine which file
to read default values from, so it's only logical to write them to the
same file.
PR: 231653
Reviewed by: eugen, bapt
Approved by: re (gjb), kib (mentor)
Differential Revision: https://reviews.freebsd.org/D17566
It was also leading to segfaults; pw can be NULL when control reaches these
lines now, because of the way my previous change restructured the loops.
Reported by: lwhsu@
pw_scan(3) has been fixed in a way that doesn't perturb other callers of
it or the getpwnam(3) family.
Make pw(8) showuser work the same with or without -R <path> for non-root
users. Without -R, pw(8) uses getpwnam(3), which will open master.passwd
for the root user or passwd for non-root users. With -R <path> pw(8) was
always opening <path>/master.passwd, which would fail for a non-root user,
then falsely claim the userid you're trying to show doesn't exist.
Now for a non-root user it opens <path>/passwd, and populates the fields in
the returned struct passwd which aren't present in that file with well-known
canonical values, which duplicates the behavior of getpwnam(3). The net
effect is that the showuser output is identical whether using -R or not.
