On Mon, 9 Jul 2012 17:04:39 -0400, Ted Ts'o <tytso@xxxxxxx> wrote: > 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. Yes this is my bad, bad name was chosen. When people hear about subtree they do expect to see a true subtree (ADG). But the feature i want to add is not about true subtree hierarchy, this is just an 3'rd inode's identifier similar to uid/gid, subtree hierarchy is just one of most obvious use-case. I just want to pick the best name for the feature May be it would be better if i describe feature as "Namespace ID" namespaces is well known abstraction in kernel, so misunderstanding shouldn't happen. Updated feature description: 1) Add XID (extension ID) the 3'rd inode's identifier similar to UID/GID 2) XID is stored inside xattr 3) XID is obtained from current task from current->cred->xid 4) XID is initialized on clone() according to namespace->xid Obviously one can understand xid as "chroot id", "container id", or "process-set id" What do you think about that description? > > 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. Definitely, this should be restricted to CAP_SYS_ADMIN > > I also worry that this feature will have very limited applicability. > Will anyone other than parallels use it? Off course no, this is very useful feature, but seems no one know about this yet :). Third quota identifier should be usefully in following cases: 1) Various containers implementation XLR and others 2) Chroot environments. For example I have an Android chroot environment and i want to prevent it from eat all space on my disk. 3) NFS: Per-mount quota. Server administrator is able to assign global disk limit for single nfs-share w/o limiting uid/gid quotas > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
