linux-kernel - 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:	Sun, 8 Aug 2010 08:53:01 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Jeremy Allison <jra@...ba.org>
Cc:	Neil Brown <neilb@...e.de>, utz lehmann <lkml123@...4n2c.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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-fsde@...per.es
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make
 extended  file stats available [ver #6]

On Sun, 8 Aug 2010 05:12:09 -0700
Jeremy Allison <jra@...ba.org> wrote:

> On Fri, Aug 06, 2010 at 01:38:36PM +1000, Neil Brown wrote:
> > I'm curious.  Why do you particularly care what interface the kernel uses to
> > provide you with access to this attribute?
> 
> It's a matter of taste. The *BSD's have this right IMHO. It
> should be part of the stat information. A file timestamp is not
> an EA. Making it available that way just feels like an appalingly
> tasteless kludge. It offends the artist in me :-).
> 

It would be more convenient if this were part of stat() but adding a
new stat call is non-trivial. Even if we did that, it still doesn't
solve the problem of being able to set the create time. The fact that
that's rarely done doesn't really matter much -- we ought to shoot for
the semantics that are needed to handle this properly.

If we do settle on a xstat() interface, it might also end up being able
to report things like selinux labels which are also available and
settable via xattr. I don't see a problem with presenting the same data
via multiple interfaces. If presenting this data via xattr solves the
immediate problem of being able to properly store and report the create
time then it seems like a win.

> > Or do you really want something like BSD's 'btime' which as I understand it
> > cannot be set.  Would that be really useful to you?
> 
> It is *already* useful to us, and is widely used in
> existing code. The occasions when btime is set are
> relatively rare, and at that point we store it in a
> separate EA for Windows reporting purposes.
> 

If that's the case, don't you have to query for this EA every time you
need to return the create time anyway? If so, then doing this really
isn't any more costly -- you'd just be querying a different EA, right?

-- 
Jeff Layton <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/