linux-kernel - Re: Versioning file system

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]

Date:	Mon, 18 Jun 2007 15:56:03 -0700 (PDT)
From:	alan <alan@...eserver.org>
To:	Jörn Engel <joern@...fs.org>
cc:	Theodore Tso <tytso@....edu>, "H. Peter Anvin" <hpa@...or.com>,
	Bodo Eggert <7eggert@....de>,
	Jack Stone <jack@...keye.stone.uk.eu.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org, viro@...iv.linux.org.uk
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