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]

Message-ID: <20100722162712.GB10352@jeremy-laptop>
Date:	Thu, 22 Jul 2010 09:27:12 -0700
From:	Jeremy Allison <jra@...ba.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Volker.Lendecke@...net.de, David Howells <dhowells@...hat.com>,
	Jan Engelhardt <jengelh@...ozas.de>,
	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, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote:
> On Thu, Jul 22, 2010 at 8:36 AM, Volker Lendecke
> <Volker.Lendecke@...net.de> wrote:
> >
> > The nice thing about this is also that if this is supposed
> > to be fully usable for Windows clients, the birthtime needs
> > to be changeable. That's what NTFS semantics gives you, thus
> > Windows clients tend to require it.
> 
> Ok. So it's not really a creation date, exactly the same way ctime
> isn't at all a creation date.
> 
> And maybe that actually hints at a better solution: maybe a better
> model is to create a new per-thread flag that says "do ctime updates
> the way windows does them".
> 
> So instead of adding another "btime" - which isn't actually what even
> windows does - just admit that the _real_ issue is that Unix and
> Windows semantics are different for the pre-existing "ctime".
> 
> The fact is, windows has "access time", "modification time" and
> "creation time" _exactly_ like UNIX. It's just that the ctime has
> slightly different semantics in windows vs unix. So quite frankly,
> it's totally insane to introduce a "birthtime", when that isn't even
> what windows wants, just because people cannot face the actual real
> difference.
> 
> Tell me why we shouldn't just do this right?

No, ctime isn't the same as Windows "create time". Windows
"create time" semantics are that the timestamp is set to
current time on file creation, but afterwards anyone with
sufficient access can then modify it (!). Which is different
from the "birthtime" spec on *BSD, as they can't be modified.

Currently on *BSD we look for our special EA containing any
modified create times on a file, and return that as "create
time" if found, if not we return the st_birthtime from the
stat struct. That works well enough for systems where you
don't want to allow birthtime to be changed. Having said
that I'm not sure how they cope with doing restores to
a filesystem where you would need to set st_birthtime :-).

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