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: <20100807210422.0b8ce265@notabene>
Date:	Sat, 7 Aug 2010 21:04:22 +1000
From:	Neil Brown <neilb@...e.de>
To:	Jeff Layton <jlayton@...ba.org>
Cc:	Steve French <smfrench@...il.com>, Jeremy Allison <jra@...ba.org>,
	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 Sat, 7 Aug 2010 06:34:00 -0400
Jeff Layton <jlayton@...ba.org> wrote:

> On Sat, 7 Aug 2010 13:32:40 +1000
> Neil Brown <neilb@...e.de> wrote:
> 
> > So we are left with an attribute that is needed for windows compatibility,
> > and so just needs to be understood by samba and wine.  Some filesystems might
> > support it efficiently, others might require the use of generic
> > extended-attributes, still others might not support it at all (I guess you
> > store it in some 'tdb' and hope it works well enough).
> > 
> > Core-linux doesn't really need to know about this - there just needs to be a
> > channel to pass it between samba/wine and the filesystem. xattr still seems
> > the best mechanism to pass this stuff around.  Team-samba can negotiate with
> > fs developers to optimise/accelerate certain attributes, and linux-VFS
> > doesn't need to know or care (except maybe to provide generic non-blocking or
> > multiple-access interfaces).
> > 
> 
> IIUC, you're saying that we should basically just have samba stuff the
> current time into an xattr when it creates the file and leave the
> filesystems alone. If so, I disagree here.

I'm not quite saying that (though there is a temptation).  Some attributes
are initialised by the filesystem rather than by common code.  i_uid is a
simple example.  I have no problem with the filesystem initialising the
storage that is used for this well-known-EA to the current time at creation.
This would be part of what team-samba negotiated with FS developers.

> 
> The problem with treating this as *just* an xattr is that it doesn't
> account for files that are created outside of samba but are then shared
> out by it.

If something is created in a different universe, then brought into this one -
when is its date of birth?  The moment of creation, or the moment of entry
into this universe?   If both universes have a common time line (altough
with a 10 year offset) then I guess the former, though I think it is a bit of
a philosophical point.... :-)

> 
> To handle this correctly, I believe it needs to be initialized by the
> kernel to the current time whenever an inode is created, even if samba
> doesn't create it. After that, it can be treated as just another xattr.
> 
Yes, I suspect that would be ideal, and trivial for the fs to implement (it
has to initialise it to something after all).

i.e. I agree.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ