Messages in this thread | | | Date | Mon, 18 Jun 2007 15:56:03 -0700 (PDT) | From | alan <> | Subject | Re: Versioning file system |
| |
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 | |