linux-ext4 - Re: [PATCH 2/3] ext4: Implement subtree ID support for ext4 filesystem

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, 9 Jul 2012 17:04:39 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	jack@...e.cz
Subject: Re: [PATCH 2/3] ext4: Implement subtree ID support for ext4
 filesystem

On Mon, Jul 09, 2012 at 07:28:44PM +0400, Dmitry Monakhov wrote:
> * Abstract
>   A subtree of a directory tree T is a tree consisting of a directory
>   (the subtree root) in T and all of its descendants in T.
> 
>   *NOTE*: User is allowed to break pure subtree hierarchy via manual
>           id manipulation.
> 
>   Subtree subtrees assumptions:
>   (1) Each inode has an id. This id is persistently stored inside
>       inode (xattr, usually inside ibody)
>   (2) Subtree id is inherent from parent directory
                      ^^^^^^^^ inherited

What really bothers me about this patch is that the abstraction is
extremely leaky.  In particular, it's not just "manual id
manipulation" that will break the abstraction.  If you rename a file
or directory across subtrees, it breaks the abstraction; so does hard
links.

When you get right down to it, this is effectively a secondary group
id, except it's not used for access control, but rather for quota
tracking.  You've used the name "subtree" id, but in fact there's no
guarantee subtrees has anything to do with it.  With a few renames,
any semblance of a subtree organization seems to disappear very
easily.

Another question which gets raised is is allowed to change the project
ownership?  Maybe I'm missing something, but I don't see any access
checking, so today it seems the answer is "anybody".  We could change
it so that only a root process can change project ownership, that
could raise other problems.

I also worry that this feature will have very limited applicability.
Will anyone other than parallels use it?

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html