linux-ext4 - Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]

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]

Date:	Thu, 22 Jul 2010 13:16:07 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Jan Engelhardt <jengelh@...ozas.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jeremy Allison <jra@...ba.org>, Volker.Lendecke@...net.de,
	David Howells <dhowells@...hat.com>,
	linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make
 extended file stats available [ver #6]

On Thu, 2010-07-22 at 19:03 +0200, Jan Engelhardt wrote:
> On Thursday 2010-07-22 18:40, Linus Torvalds wrote:
> 
> >On Thu, Jul 22, 2010 at 9:27 AM, Jeremy Allison <jra@...ba.org> wrote:
> >> On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote:
> >>> Tell me why we shouldn't just do this right?
> >>
> >> No, ctime isn't the same as Windows "create time".
> >
> >Umm. What kind of reading problems do you guys have?
> >
> >I know effin well that ctime isn't the same as Windows create time.
> >THAT WAS MY POINT.
> >
> >But the fact is, th Unix ctime semantics are insane and largely
> >useless. There's a damn good reason almost nobody uses ctime under
> >unix.
> 
> I beg to differ. ctime is not completely useless. It reflects changes on 
> the inode for when you don't you change the content. It's like an mtime 
> for the metadata. It comes useful when you go around in your filesystem 
> trying to figure out who of your co-admins screwed up the permissions on 
> /etc/passwd... and if the mtime is the same as that of the last backup, 
> I can at least have a reasonable assurance that it was /only/ the 
> metadata that was tampered with. (SHA1 check, yeah yeah, costly on large 
> files.)

Errr... Only if you eliminate utimes() from your syscall table.
Otherwise it is trivial to reset the mtime after changing the file
contents.

Cheers
  Trond

--
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