linux-kernel - Re: reiser4: maybe just fix bugs?

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: <5c49b0ed0608011226w328d809fy9d50aa785ad93536@mail.gmail.com>
Date:	Tue, 1 Aug 2006 12:26:38 -0700
From:	"Nate Diller" <nate.diller@...il.com>
To:	"David Masover" <ninja@...phack.com>
Cc:	"Vladimir V. Saveliev" <vs@...esys.com>,
	"Andrew Morton" <akpm@...l.org>, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, Reiserfs-List@...esys.com
Subject: Re: reiser4: maybe just fix bugs?

On 8/1/06, David Masover <ninja@...phack.com> wrote:
> Vladimir V. Saveliev wrote:
>
> > Do you think that if reiser4 supported xattrs - it would increase its
> > chances on inclusion?
>
> Probably the opposite.
>
> If I understand it right, the original Reiser4 model of file metadata is
> the file-as-directory stuff that caused such a furor the last big push
> for inclusion (search for "Silent semantic changes in Reiser4"):
>
> foo.mp3/.../rwx    # permissions
> foo.mp3/.../artist # part of the id3 tag
>
> So I suspect xattrs would just be a different interface to this stuff,
> maybe just a subset of it (to prevent namespace collisions):
>
> foo.mp3/.../xattr/ # contains files representing attributes
>
> Of course, you'd be able to use the standard interface for
> getting/setting these.  The point is, I don't think Hans/Namesys wants
> to do this unless they're going to do it right, especially because they
> already have the file-as-dir stuff somewhat done.  Note that these are
> neither mutually exclusive nor mutually dependent -- you don't have to
> enable file-as-dir to make xattrs work.
>
> I know it's not done yet, though.  I can understand Hans dragging his
> feet here, because xattrs and traditional acls are examples of things
> Reiser4 is supposed to eventually replace.
>
> Anyway, if xattrs were done now, the only good that would come of it is
> building a userbase outside the vanilla kernel.  I can't see it as doing
> anything but hurting inclusion by introducing more confusion about
> "plugins".
>
> I could be entirely wrong, though.  I speak for neither
> Hans/Namesys/reiserfs nor LKML.  Talk amongst yourselves...

i should clarify things a bit here.  yes, hans' goal is for there to
be no difference between the "xattr" namespace and the "readdir" one.
unfortunately, this is not feasible with the current VFS, and some
major work would have to be done to enable this without some
pathological cases cropping up.  some very smart people think that it
cannot be done at all.

xattr is a seperate VFS interface, which avoids those problems by
defining certain restrictions on how the 'files' which live in that
namespace can be manupulated.  for instance, hard links are
non-existent, and the 'mv' command cannot move a file between
different xattr namespaces.

enabling xattr would have no connection to the file-as-directory
stuff, and (without extra work) would not even allow access to the
things reiser4 defined in the '...' directory.  also enabling xattr in
the way i intend would in no way compromise hans' long-term vision.

HOWEVER, i *need* to point out that hans and i disagree somewhat on
the specifics here, and so i should say adamently "i don't speak here
on behalf of hans or namesys".

that won't stop me from submitting my own patch though :)

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