Re: Thinking outside the box on file systems

[Phillip Susi <psusi@cfl.rr.com>]

Kyle Moffett wrote:
>> I am well aware of that, I'm simply saying that sucks.  Doing a 
>> recursive chmod or setfacl on a large directory tree is slow as all hell.
> 
> Doing it in the kernel won't make it any faster.

Right... I'm talking about getting rid of it entirely.

> You can't safely preserve POSIX semantics that way.  For example, even 
> without *ANY* ability to read /etc/shadow, I can easily "ln /etc/shadow 
> /tmp/shadow", assuming they are on the same filesystem.  If the 
> /etc/shadow permissions depend on inherited ACLs to enforce access then 
> that one little command just made your shadow file 
> world-readable/writeable.  Oops.

That's why /etc/shadow would have an IRM that would block inheriting any 
permissions.

> Think about it this way:
> Permissions depend on *what* something is, not *where* it is.  Under 

No, they don't.  At least not always.  A lot of times people want 
permissions based on where it is.

> Linux you can leave the digital equivalent of a $10,000 piece of jewelry 
> lying around in /var/www and not have to worry about it being 
> compromised as long as you set your permissions properly (not that I 
> recommend it).  Moving the piece of jewelry around your house does not 
> change what it *is* (and by extension does not change the protection 
> required on it), any more than "ln /etc/shadow /tmp/shadow" (or "mv") 
> changes what *it* is.  If your /house is really extraordinarily secure 
> then you could leave the jewelry lying around as /house/gems.bin with 
> permissions 0777, but if somebody had a back-door to /house (an open fd, 
> a careless typo, etc) then you'd have the same issues.

Yes, but if you move it to your front porch, you have changed the 
protection on it.  If you want to be sure of it being protected, keep it 
locked up in a safe... in other words, use the IRM.

> Not necessarily.  When I do "vim some-file-in-current-directory", for 
> example, the kernel does *NOT* look up the path of my current 
> directory.  It does (in pseudocode):
> 
> if (starts_with_slash(filename)) {
>     entry = task->cwd;
> } else {
>     entry = task->root;
> }
> while (have_components_left(filename)
>     entry = lookup_next_component(filename);
> return entry;

Right.... and task->cwd would have the effective acl in memory, ready to 
be combined with any acl set on the file.

> That's not even paying attention to functions like "fchdir" or their 
> interactions with "chroot" and namespaces.  I can probably have an open 
> directory handle to a volume in a completely different namespace, a 
> volume which isn't even *MOUNTED* in my current fs namespace.  Using 
> that file-handle I believe I can "fchdir", "openat", etc, in a 
> completely different namespace.  I can do the same thing with a chroot, 
> except there I can even "escape":
>   /* Switch into chroot.  Doesn't drop root privs */
>   chdir("/some/dir/somewhere");
>   chroot(".");
> 
>   /* Malicious code later on */
>   chdir("/");
>   chroot("another_dir");
>   chdir("../../../../../../../../..");
>   chroot(".");
>   /* Now I'm back in the real root filesystem */

I don't see what this has to do with this discussion, and I also can't 
believe that is correct... the chdir( "../../../../.." ) should fail 
because there is no such directory.

> The locking penalty is because the path-lookup is *not* implied.  The 
> above chroot example shows that in detail.  If you have to do the lookup 
> in *reverse* on every open operation then you have to either:
> 
>   (A) Store lots of security context with every open directory (cwd 
> included).  When a directory you have open is moved, you still have full 
> access to everything inside it since your handle's data hasn't changed.

Yes, the effective acl of the open directory is kept in memory, but in 
the directory itself, not the handle to it, thus when the directory is 
moved, it's acl is recomputed for the new location and updated 
immediately.  It is like using fcntl to set a file to non blocking... it 
is the file you set, not the handle to it, so it effects other processes 
that have inherited or duplicated the file.

> See above.  Linux has a very *very* powerful VFS nowadays.  It also has 
> support for shared subtrees across private namespaces, allowing things 
> like polyinstantiation.  For example you can configure a Linux box so 
> every user gets their own empty /tmp directory created and mounted on 
> their namespace's /tmp when they log in, but all the rest of the system 
> mounts are all shared.

I still can't see how these features cause a problem.