Bug 29671

Summary: restore changes attributes of directories despite "-N" flag
Product: Base System Reporter: sblank <sblank>
Component: binAssignee: dd <dd>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.4-PRERELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description sblank 2001-08-13 10:00:03 UTC
According to the restore manpage:

	-N	Do the extraction normally, but do not actually write
		any changes to disk.  This can be used to check the integrity of
		dump media or other test purposes.

This is _not_ true for the "Set directory mode, owner, and times" pass
that happens last during the restore process.

Fix: Make the routine "setdirmodes" in dirs.c respect the "-N" flag.
How-To-Repeat: 
I can reproduce it the with these steps:

1st) % ls -ld /home/sblank /home/sblank/tmp
drwxr-xr-x  42 sblank  users  3584 11 Aug 11:54 /home/sblank
drwx------   2 sblank  users   512 11 Aug 15:39 /home/sblank/tmp

2nd) % cd ~sblank

3rd) % su root

4th) # pwd
/home/sblank

5th) # restore -rNv -f ... a backup of your '/' filesystem

6th) # ls -ld /home/sblank /home/sblank/tmp
drwxr-xr-x  42 root    wheel  3584 11 Aug 11:54 /home/sblank
drwxrwxrwt   2 root    wheel   512 11 Aug 15:39 /home/sblank/tmp


The change of the attributes happens because the "Set directory mode, owner,
and times" pass ignores the -N flag.  Normaly you don't notice unless it
tries to change the attribues of a directory that happens to live under
the same name relative to the directory where you have started restore
from.

To explain this particular example: The "Set directory mode, owner, and
times" pass also runs across the directories "." and "./tmp" during its
course.  Since I have started restore from my home directory every
directory that is found on the backup is looked up to see if it already
exists relative to my home directory.  Since "/home/sblank/." and
"/home/sblank/tmp" happen to exist in this case, they are changed to
what the backup says.  The result of this can be seen in step 6.

Attention: Though it might look like this problem can only happen when
restore is run by root, this is not strictly true: looking at the code
in "setdirmodes" one can see that the chmod() and utimes() calls can
even succeed when restore is run by an unpriviledged user.  Though no
real damage can be done in this case it might be surprising nonetheless
to see that certain directories suddenly have other attributes than
expected.
Comment 1 dd freebsd_committer freebsd_triage 2001-08-14 06:31:06 UTC
Responsible Changed
From-To: freebsd-bugs->dd

Excellent analysis, I'll apply this in a few days.
Comment 2 dd freebsd_committer freebsd_triage 2001-08-20 03:15:40 UTC
State Changed
From-To: open->closed

Patch applied to current, and will be MFC'd after the release.  Thanks 
for your excellent analysis!