Re: Filesystem Capabilities in 2.6?

Linus Torvalds (torvalds@transmeta.com)
Sun, 3 Nov 2002 10:42:50 -0800 (PST)


On Sun, 3 Nov 2002 yodaiken@fsmlabs.com 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.

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