Reject the absurd user and group names "." and "..".

[brooks]

Summary

This prevents the creation of absurd password entries like:
..:*:1002:1002:User &:/home/..:/bin/sh

PR: 224556
Reported by: [e-mail]

[bcr]

Minor wording fixes.

usr.sbin/pw/pw_user.c

645

I would remove "absurd" from the comment, to make the sentence sound more neutral.

[brooks]

• Tweak wording as suggested by @bcr.

[brooks]

Add people who have touched pw as possible reviewers.

[asomers]

What makes . and .. more bogus that ...? The PR says, bug the comment does not. The comment should say something about preventing unintended default home directories that are too encompassing. But . and .. aren't the only special directories. What about .zfs, .snap, and .sujournal? And if /home is mounted over NFS, then there may be other special files as well. For example, Netapp creates a .snapshot directory.

Furthermore, what would happen on upgrade to a FreeBSD system that already has a user named .? Would the new pw command refuse to modify that user? I think it might make more sense to allow such usernames, but prevent their home directories from being set to special stuff like /home/..

[eugen_grosbein.net]

Initial submitter of the PR 224556 is a bit too rash.

There is nothing wrong with /. or /.. in user's home directory. Despite of them look unusual, they perform just fine and sometimes even do useful job.
For example, syntax "/usr/local/ftp/./pub" is documented within our ftpd(8) manual page for user "ftp" and its initial current directory "pub" for ftp session chrooted for "/usr/local/ftp".

Our "pw userdel" already handles this just fine. It won't even try to remove .zfs nor .snap, .sujournal or anything not belonging to user being removed.
I do not think we have a problem here.

[brooks]

Seems to be unnecessary. I don't like the way some defaults work out, but *shrug*.