Red Hat Bugzilla – Bug 89591
useradd home creation defaults dangerous and confusing
Last modified: 2007-04-18 12:53:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Description of problem:
useradd by default creates a new user directory and populates it with the files
from /etc/skel. If the directory already exists, it is not created anew but the
files from /etc/skel are still copied.
This behavior is dangerous and the documentation does nothing to indicate that
this is the default behavior.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create /home/foo manually.
2. Create a fake /home/foo/.bashrc.
3. Execute: useradd -d /home/foo foo.
Actual Results: .bashrc is overwritten.
Expected Results: .bashrc should not be overwritten.
Suggested solutions, in order of decreasing preference:
1. If a skel file already exists in the new home, don't overwrite it.
2. If the home already exists, don't copy the skel files.
3. Backup any skel files that are going to be overwritten.
4. Change the behavior back to the original default of useradd which is to not
The documentation is also not quite clear. Here is what man has to say:
-m The userâs home directory will be created if it does not exist.
The files contained in skeleton_dir will be copied to the home
directory if the -k option is used, otherwise the files con-
tained in /etc/skel will be used instead. Any directories con-
tained in skeleton_dir or /etc/skel will be created in the
userâs home directory as well. The -k option is only valid in
conjunction with the -m option. The default is to not create
the directory and to not copy any files.
It doesn't make it clear that the file copying happens whether or not a new home
directory is actually created. The fact that the copying happens whether or not
the home already exists should be made explicit. Also it says the default is
not to create the directory but it should also mention that /etc/login.defs can
override this default behavior. (And login.defs should get proper documentation
too.) This is what bit me: I read the above and thought useradd would not
attempt to create the directory (or copy any files) since there was no
indication that /etc/login.defs would override that behavior.
*** Bug 158574 has been marked as a duplicate of this bug. ***
fixed since shadow-utils-4.0.7-10.FC4