Bug 278571 - Situation where "usermod -d newdir -m userid" changes modtimes of user's files
Situation where "usermod -d newdir -m userid" changes modtimes of user's files
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-05 11:13 EDT by Robert K. Moniot
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-31 05:25:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Robert K. Moniot 2007-09-05 11:13:46 EDT
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 
files
"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):
shadow-utils-4.0.18.1-15.fc7

How reproducible: 
Always


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 11:56:45 EDT
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 07:45:46 EDT
Created attachment 228581 [details]
fix candidate

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