linux-ext4 - Re: [RFC] [PATCH 3/3] Recursive mtime for ext3

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: <20071107115110.GC22214@duck.suse.cz>
Date:	Wed, 7 Nov 2007 12:51:10 +0100
From:	Jan Kara <jack@...e.cz>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [RFC] [PATCH 3/3] Recursive mtime for ext3

On Tue 06-11-07 10:04:47, H. Peter Anvin wrote:
> Arjan van de Ven wrote:
> >On Tue, 6 Nov 2007 18:19:45 +0100
> >Jan Kara <jack@...e.cz> wrote:
> >
> >>Implement recursive mtime (rtime) feature for ext3. The feature works
> >>as follows: In each directory we keep a flag EXT3_RTIME_FL
> >>(modifiable by a user) whether rtime should be updated. In case a
> >>directory or a file in it is modified and when the flag is set,
> >>directory's rtime is updated, the flag is cleared, and we move to the
> >>parent. If the flag is set there, we clear it, update rtime and
> >>continue upwards upto the root of the filesystem. In case a regular
> >>file or symlink is modified, we pick arbitrary of its parents
> >>(actually the one that happens to be at the head of i_dentry list)
> >>and start the rtime update algorith there.
> >
> >Ok since mtime (and rtime) are part of the inode and not the dentry...
> >how do you deal with hardlinks? And with cases of files that have been
> >unlinked? (ok the later is a wash obviously other than not crashing)
  Unlinked files are easy - you just don't propagate the rtime anywhere.
For hardlinks see below.

> There is only one possible answer... he only updates the directory path 
> that was used to touch the particular file involved.  Thus, the 
> semantics gets grotty not just in the presence of hard links, but also 
> in the presence of bind- and other non-root mounts.
  Update of recursive mtime does not pass filesystem boundaries (i.e.
mountpoints) so bind mounts and such are non-issue (hmm, at least that was
my original idea but as I'm looking now I don't handle bind mounts properly
so that needs to be fixed). With hardlinks, you are right that the
behaviour is undeterministic - I tried to argue in the text of the mail
that this does not actually matter - there are not many hardlinks on usual
system and so the application can check hardlinked files in the old way -
i.e. look at mtime.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html