Bug 278571 - Situation where "usermod -d newdir -m userid" changes modtimes of user's files
Summary: Situation where "usermod -d newdir -m userid" changes modtimes of user's files
Alias: None
Product: Fedora
Classification: Fedora
Component: shadow-utils
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: Fedora Extras Quality Assurance
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2007-09-05 15:13 UTC by Robert K. Moniot
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2007-10-31 09:25:53 UTC

Attachments (Terms of Use)
fix candidate (2.12 KB, patch)
2007-10-16 11:45 UTC, Peter Vrabec
no flags Details | Diff

Description Robert K. Moniot 2007-09-05 15:13:46 UTC
Description of problem:

We have a number of hosts that share home dirs over NFS using a scheme whereby /
u/host is automounted from hostname:/home/users.  That is, the real home 
directory is hostname:/home/users/username, but in the password file the home 
dir is listed as /u/hostname/username, and automount takes care of making them 
the same, even on the host where the directory resides.

Recently I moved some users who were irregularly placed in /home to /home/users 
and discovered the following:

The behavior of "usermod -d newdir -m userid" differs depending on whether the 
real dir or the automounted synonym is used:
"usermod -d /home/users/userid -m userid" preserves the modtimes of the user's 
"usermod -d /u/host/userid -m userid" changes the modtimes of all the files to 
the time of the move.

I don't see why this should happen, since mv preserves modtimes, even when the 
destination directory is aliased via automount this way.

Version-Release number of selected component (if applicable):

How reproducible: 

Steps to Reproduce:
1. Create a partition, e.g. /home.  Create a subdirectory /home/users
2. Create an automount entry in /etc/auto.home saying "* &:/home/users".  Make 
sure that /u/hostname shows the same contents as /home/users, where hostname is 
the name (without domain) of the local host.  You do not need to create an 
entry in /etc/exports since this test is done on the local host.  The behavior 
of usermod is the same whether /home/users is exported or not.
3. Use "useradd -d /home/testuser testuser" to create a user with home dir /
home/testuser.  Populate with some files and use touch to backdate them, or 
else wait a little while so the next step will occur at a noticeably different 
system time than the file creations.  Use "ls -l ~testuser" to see the modtimes.
4. Use "usermod -d /home/users/testuser -m testuser" to move the user's home 
dir.  Use "ls -l ~testuser" to see that the file modtimes are unchanged.
5. Use "usermod -d /home/testuser -m testuser" to move the home dir back.  Use 
"ls -l ~testuser" to verify that modtimes are still unchanged.
6. Now use "usermod -d /u/hostname/testuser -m testuser" to move the user's 
home dir to /u/hostname/testuser which is the same as /home/users/testuser. Use 
"ls -l ~testuser" to see the modtimes of the files, now changed to that of the 
time at which step 4 was executed.
7. To show that this does not need to happen, find any file and use "mv file /u/
hostname/" and see its modtime is not changed.
Actual results:
Modtimes of user's files become those of the usermod execution.

Expected results:
Modtimes of user's files should be unchanged by the move.

Additional info: The workaround for this bug is to use /home/users/testuser in 
the usermod command, then use vipw to change the home dir to /u/hostname/
testuser in /etc/passwd.

Comment 1 Tomas Mraz 2007-09-05 15:56:45 UTC
The reason is because in the first case a rename() of the directory is used
which of course preserves all the timestamp. In the mounted dir case it cannot
be used so the tree is copied and then removed on the original location. The
copy_tree() function in shadow utils doesn't set modification timestamps on the
new files to the values of the original files.

Comment 2 Peter Vrabec 2007-10-16 11:45:46 UTC
Created attachment 228581 [details]
fix candidate

Note You need to log in before you can comment on or make changes to this bug.