One other observation about EROS: Capabilities are also very old
concept, dating back at least 20 years. The one challenge with using
them, though, is that it completely guts your hope of being POSIX.1
compatible. For example, the open() system call must now take a new
argument, which is the capability. So does unlink(), and rename(), and
bind(), and accept().....
On the one hand, this is good --- very good --- it means that you don't
have the problem of accidentally running something with superuser privs
when you didn't expect them to, since the privilege management is called
out explicitly as part of the API. It's a bit more annoying for the
programmers (especially programmers of networked services like ftpd and
httpd), who now have to manage capabilities explicitly, but that's the
price you pay for the improved security
On the flip side, the lack of compatibility means that lose all of the
Unix utilities (the GNU suite of utilities, the X window system, etc.).
This doesn't mean that a capability system which becomes used in the
real world will never happen, but it does increase the energy barrier of
making a useful system appear much, much harder. One of the reasons why
Linux took off so quickly was that he were able to reuse userspace
tools. Moving to a pure capability-based scheme will mean losing all of
that.
Now, you could solve the problem by having a compatibility layer;
however, within that compatibility layer, you won't have any of the
benefits of capabilities, either. So now the game is trying to convince
all of the application programmers to rewrite their programs in order to
be able support the new capability-based OS. Again, not impossible, but
the activation energy can be quite high.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/