Re: Versioning file system

[alan <alan@clueserver.org>]

On Tue, 19 Jun 2007, Jörn Engel wrote:

> On Mon, 18 June 2007 18:10:21 -0400, Theodore Tso wrote:
> > On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
> > > And that makes them different from extended attributes, how?
> > >
> > > Both of these really are nothing but ad hocky syntactic sugar for
> > > directories, sometimes combined with in-filesystem support for small
> > > data items.
> >
> > There's a good discussion of the issues involved in my LCA 2006
> > presentation....  which doesn't seem to be on the LCA 2006 site.  Hrm.
> > I'll have to ask that this be fixed.  In any case, here it is:
> >
> > 	http://thunk.org/tytso/forkdepot.odp
>
> The main difference appears to be the potential size.  Both extended
> attributes and forks allow for extra data that I neither want or need.
> But once the extra space is large enough to hide a rootkit in, it
> becomes a security problem instead of just something pointless.
>
> Pointless here means that _I_ don't see the point.  Maybe there are
> valid uses for extended attributes.  If there are, noone has explained
> them to me yet.

Most of the extended attribute systems I have seen have been a set of 
flags.  "If this bit is set, the user can do thus to this object." 
Sometimes it is a named attribute that is attached to the object.

Forks tend to be "this blob of data is attached to this object".

With forks, the choices tend to be a lot more arbitrary.

--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
                                  - Alan Cox