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
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
Two PRs (152084 & 210187) request allowing the "@" and/or "!"
characters in the passwd file GECOS field. The man page for pw does
not mention that those characters are disallowed, Linux supports those
characters in this field, and the "@" character in particular would be
useful for storing email addresses in that field.
PR: 152084, 210187
Submitted by: jschauma@netmeister.org, Dave Cottlehuber <dch@freebsd.org>
Reported by: jschauma@netmeister.org, Dave Cottlehuber <dch@freebsd.org>
Reviewed by: delphij (secteam), vangyzen
MFC after: 1 week
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D14519
Fix it and rename misnamed time_t variables `expire_days, password_days'
(always holding absolute time) to `expire_time, password_time'.
Add a comment for a case of overloading `cmdcnf->password_days'
and `cmdcnf->expire_days' with absolute time.
Reported by: markj
Approved by: mav (mentor)
MFC after: 1 week
to preconfigured values for -e, -p and -w flags.
Use non-negative symbols instead of magic values
in passwd_val/pw_password functions.
PR: 223431
Submitted by: Yuri Pankov (in part, patch for the manual)
Reported by: mav (mentor)
MFC after: 3 days
Relnotes: yes
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
Previouly it was possible to create users with spaces in the name with:
pw useradd -u 1234 -g 1234 -n 'test user'
The "-g 1234" is relevant, without it the name was already rejected
as expected:
[fk@test ~]$ sudo pw useradd -u 1234 -n 'test user'
pw: invalid character ` ' at position 4 in userid/group name
Bug unintentionally found with a salt config without explicit name entry:
test user:
user.present:
- uid: 1234
- gid: 1234
- fullname: Test user
- shell: /usr/local/bin/bash
- home: /home/test
- groups:
- wheel
- salt
"Luckily" salt modules rarely bother with input validation either ...
PR: 221416
Submitted by: Fabian Keil
Obtained from: ElectroBSD
MFC after: 1 week
"pw usermod someuser -G ''" is supposed make sure that someuser
doesn't have any secondary group memberships.
Previouly it was a nop because split_groups() only intitialised
"groups" if at least one group was specified. As a result the
existing secondary group memberships were kept.
PR: 221417
Submitted by: Fabian Keil
Obtained from: ElectroBSD
MFC after: 1 week
Relnotes: yes
Otherwise, it will silently disable the login for the selected account if
the argument is unrecognizable.
usr.sbin/pw/pw.h
usr.sbin/pw/pw_conf.c
usr.sbin/pw/pw_user.c
Use separate rules to validate boolean parameters and passwd
parameters. Error out if a password parameter cannot be parsed.
usr.sbin/pw/tests/Makefile
usr.sbin/pw/tests/crypt.c
usr.sbin/pw/tests/pw_useradd.sh
usr.sbin/pw/tests/pw_usermod.sh
Add tests for the validation. Also, enhance existing
password-related tests to actually validate that the correct hash is
written to master.passwd.
Reviewed by: bapt
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D6840
relax it a bit so gecos can be used to store multibytes data.
This was unseen before FreeBSD 10.2 as this validation function was motly unused
since FreeBSD 10.2 the usage of this function has been generalized to improve
validation.
Reported by: des
MFC after: 1 week
because it is also used as an indicator of whether a name or an UID is
being used and we may have undefined results as 'name' may contain
uninitialized stack contents.
MFC after: 2 weeks
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
MFC after: 2 days
Readd the function to create the parents home directory if it does not exists.
if it is only a directory at the top level of the hierarchy symlink it into /usr
as it used to be done before.
Reported by: kevlo, adrian
/usr/home/adrian/work/freebsd/head-embedded-2/src/usr.sbin/pw/pw_user.c: In function 'pw_user_next':
/usr/home/adrian/work/freebsd/head-embedded-2/src/usr.sbin/pw/pw_user.c:680: warning: statement with no effect
Now each subcommands checks its arguments in a dedicated functions.
This helps improving input validation, code readability/maintainability
While here:
- Add a -y option to pw userdel/usermod so it can maintain NIS servers if
nispasswd is not defined in pw.conf(5)
- Allow pw -r <rootdir> to remove directory with userdel -r
- Fix bug when renaming a user which was not renaming the user name it groups
it is a member of.
- Only parse pw.conf(5) when needed.
supposed to be manipulated
This prevent pw usermod creating a new local user when requesting to usermod on
a username is defined in LDAP.
This issue only happens when modifying the local user database (not inpacting
commands when -V or -R are used).
PR: 187653
Submitted by: tmwalaszek@gmail.com
Rewrite rm_r to use *at function, allowing to remove home directories along with
users. only crontabs and at(1) installation are not removed
Relnotes: yes
