Debian-based
If you are on a Debian-based system, the new - already somewhat present by default in multiple debian-based distributions, (as well as already included in the source code of both pwck
and login.defs
of the next shadow-utils
package release) proper way to account for nonexistent home directories is with the /nonexistent
path.
If you actually get the newest shadow-utils
package , it will allow you to configure your /etc/login.defs
and add (or uncomment) the following option:
This is from the new man 8 pwck
from the latest commit:
NONEXISTENT (string)
If a system account intentionally does not have a home directory
that exists, this string can be provided in the /etc/passwd entry
for the account to indicate this. The result is that pwck will
not emit a spurious warning for this account.
and the actual option belongs in /etc/login.defs
like so
# The [string] can be whatever word/path you want to use in your /etc/passwd file to
# correspond to a nonexistent directory. However, /nonexistent should be used as the default
# nonexisting home directory, as that is already in use in many distributions.
NONEXISTENT [string]
This option has been added specifically for pwck
to account for nonexistent home directories, which is the underlying command used by the shadow.service
that checks the validity and integrity of /etc/passwd
using the configuration provided in /etc/login.defs
.
If you do use this configuration option, then using sudo adduser -M -d /nonexistent [username]
followed by pwck -r
will not throw an error.
Other distributions
While many Debian-based distributions already use this approach for this particular situation, there are other variants which use their own system to account for nonexistent home directories.
However, you can usually test how your distribution already determines the nonexistent home directory situation, by executing
sudo grep nobody /etc/passwd
as this particular non-privileged user will never by default have its own home directory path, yet the corresponding value found in your /etc/passwd
will give you a clue of how your system already deals with it.
For example:
RHEL/CentOS uses /
as a fail-safe for home directory of nobody
yet disables its login shell through /sbin/nologin
Debian-based distros currently use /nonexistent
for home directory, and /usr/sbin/nologin
for the shell
SUSE Linux, until at least mid 2019, used /var/lib/nobody
for the directory and /bin/bash
for the shell, but some security-conscious memos suggest a change to /var/lib/nobody
and /bin/false
OSx used and might still use /var/empty
and /usr/bin/false
for nobody
I have encountered other distributions that use /nonexistent
yet allow for shell with /bin/sh
The issue with using sudo useradd [username]
is that it specifically allows for system preset options in /etc/login.defs
to be overwritten at execution, even if they may violate the integrity of /etc/passwd
.
I have not tested useradd
in a while, but - unless significant changes have been made to the source code - the validator for the -d
option flag had many limitations. There was certainly a check present for whether optarg[0]
of the provided path is indeed /
and whether a path contains :
but every test I ran using *
, and hence I would not be surprised if sudo useradd -d /home/my:base [username]
actually executed without error.
/etc/passwd
which do not require or should have a home directory (which is nothing new) and I believe the proper method or convention to do such a thing is with either/bin/true
or/bin/false
specified as the home directory.(usermod) -s
specifies the shell./bin/false
would be a regular file, that could cause issues (trycd /bin/false
). However upon closer inspection, many stocknologin
users have just/
as their home...