linux-kernel - Re: Thinking outside the box on file systems

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:	Fri, 17 Aug 2007 15:01:48 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Valdis.Kletnieks@...edu
CC:	Kyle Moffett <mrmacman_g4@....com>,
	Michael Tharp <gxti@...tiallystapled.com>,
	alan <alan@...eserver.org>, Marc Perkel <mperkel@...oo.com>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: Thinking outside the box on file systems

Valdis.Kletnieks@...edu wrote:
> I suspect Kyle is not quite correct - it's probably the case that you don't
> have to consider just the in-memory dentries, but *all* the descendent objects
> in the entire file system.
> 
> If you have a clever proof that on-disk can't *possibly* be affected, feel
> free to present it.

Why would you have to consider the descendent entries on disk when you 
are only changing an entry in the parent?  The effects of that change 
are only computed in memory when the dentry for a child is created, so 
you don't have to do a bunch of disk churning to change permissions on 
the whole tree.  In fact, all of the children may very well have NO acl 
of their own stored on disk, which also saves space.

The whole idea here is that there is ONE acl that applies to the whole 
tree, rather than have every object in the tree have its own acl. 
That's why every object in the tree on the disk is not effected by a 
change.

> It will become even *more* of a "not that common" if the lock will block moves
> and ACL changes *across the filesystem* for potentially *minutes* at a time.

It will not take anywhere NEAR minutes at a time to update the in memory 
dentries, more like 50ms.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/