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  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

Powered by blists - more mailing lists