Re: Filesystem Capabilities in 2.6?

[Linus Torvalds]

On Sun, 3 Nov 2002 [e-mail] wrote:
> 
> So capabilities then just seems like a hack.  You can write a trusted
> user space suid gateway program that consults a database, builds you a
> temporary file system with links and permissions to an otherwise hidden
> shared tree and puts you safely in that "temporary  tree". If I understand
> what this does.

That works for stuff where you are willing to live in a very limited 
environment.

Most people aren't willing to live in such environments. They want to look 
up user files in ~/.xxxxx, falling back to /usr/lib/xxxx/config, etc. And 
they want to take advantage of being able to use other programs in the 
system etc etc.

In other words, yes, you can create a temporary tree, and pretty much
arbitrarily restrict what any process can actually see of the filesystem. 
But it's a _lot_ of work, and requires a lot of care, and by limiting your 
filesystem view you limit yourself to only using that view. 

And the fact is, most programmers are lazy. They don't want to go to that 
effort, since it makes it harder for them. And you can't really blame them 
for that - especially since 99% of all projects evolve from something 
where security wasn't a big deal ("it's only for my own use anyway").

Look at how few programs bother with chroot(), and that's a lot easier to 
use (and portable). 

		Linus

PS. Yeah, to some degree namespaces are at least in theory easier to use
than chroot, since they allow for a lot more flexibility and you can
cherry-pick and do things like just re-mount /usr/bin with nosuid inside
your namespace, which chroot doesn't allow. With chroot you end up having
to copy the files explicitly and maintain a separate chroot directory
structure.