bugtraq - Re: Changes to the filesystem while find is running

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200411251024.iAPAOGBW001920@plug.fi>
Date: Thu, 25 Nov 2004 02:24:16 -0800 (PST)
From: "Troy" <tjk@...oft.com>
To: bugtraq@...ession.spiral-arm.org (James Youngman)
Cc: Troy <tjk@...oft.com>, srevilak@...akeasy.net, parimiv@...haw.com,
	martin.buchholz@....com, levon@...ementarian.org,
	bugtraq@...urityfocus.com, bug-findutils@....org
Subject: Re: Changes to the filesystem while find is running - comments?


James,

I realize now that the real problem occurs when we chdir out
of the directory; if the directory has been moved, we end up in
the new directory, not where we started.

E.g.:
chdir /usr/local
pwd
/usr/local
mv ../local /etc/
pwd
/usr/local
cd ..
pwd 
/etc

Checking the inode doesn't help, since the directory can be moved
after the check, just before we chdir back out of the directory. 
(In any case, someone moving the current directory somewhere else 
shouldn't be a problem since the files/dirs inside the current
directory aren't affected.)

I don't see any other solution but to save the inode of the
directory which contains the newly chdir'ed directory. That
way we can check that when we chdir back out. If it has changed,
then we know there is a problem and we should abort.



Troy


> 
> On Tue, Nov 23, 2004 at 01:58:00PM -0800, Troy wrote:
> > James,
> > 
> > Would it be possible to replace the sanity check for inode number with a
> > sanity check for cwd and directory name? After all, if the directory is 
> > moved (renamed or given another parent directory) while find is running, 
> > then the CWD will have changed. On the other hand, if stat'ing or chdir'ing 
> > the directory has caused automount to mount a new filesystem on it, the 
> > CWD will not have changed. This would seem to be a fix.
> > 
> > What do you think?
> 
> Checking the result of getcwd() would have substantially the right
> effect.  It encapsulates the "did we end up where we expected?"
> condition, too.
> 
> Unfortunately on most systems it's pretty expensive (it stats "." and
> then does opendir(".."), calling stat() on each entry to find the
> basename of the current directory, and then repeats this process with
> the parent directory).  That is problematic from our point of view,
> firstly because of the impact on performance but also because it does
> filesystem traversal without checking things.  Protecting ourselves
> while we are moving up the directory hierarchy also becomes a lot more
> complicated if our method of protecting ourselves does in fact move up
> the directory hierarchy itself.
> 
> There are systems on which getcwd() is actually a system call but not
> all systems are like that.
> 
> Thanks.
> James.
>