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
