It's on the URL that I gave you and that you haven't even looked at
(it's obvious because the page also includes notes on design of a UNIX
compatible system on top of pure capabilities).
> > All the features that you have named are because of a different design
> > of the operating system, don't you agree? So isn't it perhaps time that
> > we start to consider alternative concepts for mainstream operating
> > systems or at least start implementing known solutions to problems that
> > our systems have?
>
> It is interesting, and perhaps it is useful for some people.
> It is _not_ anything like Linux and can't support basic POSIX
> features very well. For example, you have to give up much of
> the security and run Unix emulation if you want a real filesystem.
> (yeah, no kidding: we get rid of open(2) and just pass fd's around)
You talk about the filesystem as something that is fundamentally a good
thing (which it is not). It's just the current way of ensuring the
persistency of data because we're not able to achieve general
persistency. A filesystem can _easily_ be emulated if you have general
persistency of objects (it's just an object that contains hierarchically
organized smaller objects), although once you have general persistency,
you don't _want_ to take a step back and implement a subsystem that has
been the source of numerous security holes. Also, the filesystem wastes
a lot of the disk's potential performance. If you on the other hand do
periodic snapshots of the system memory, the writes to the disk can be
done very fast (close to the maximum), because you don't have to seek
all the time but you simply dump the whole memory as a one block write
(or several consecutive ones).
In the same sentence, you claim that pure capabilities can't support
basic POSIX features very well. What are those basic features? And if
they can't be supported but a better alternative is provided at the same
time, why _should_ they be supported? And exactly what security has to
be given up if pure capabilities are good exactly because, among other
things, they provide _better_ security???
As for open(), you really picked a stupid example to show 'disadvantages
of pure capabilities'. Wouldn't it be an _optimization_ if you could get
rid of a neccessary step of opening a file and just access it directly?
Jezus..
> >> I hope everyone has seen this by now:
> >> http://agn-www.informatik.uni-hamburg.de/people/1ott/rsbac/index.htm
> >
> > Yes, we have seen it, but the thesys is in German
>
> I thought people were complaining about the web page in German.
> I just assumed everybody would grab to code itself, not the thesis.
Code is just the implementation of the concept. If the concept is
flawed, don't you think that the implementation will be fundamentally
flawed too?
I appologize if this mail may seem as a bit of flaming, but it really
annoys me if people put down designs without at least _trying_ to
understand them. I would be very happy if someone could provide me with
real arguments, why capability lists and ACLs are better than pure
capabilities (I assume Linux kernel developers think so because it seems
that they prefer those designs).
Andrej
PS: There's an intresting saying that I saw at the bottom of some page
about pure capabilities: Let's argue to learn, not to win..
-- Andrej Presern, andrejp@luz.fe.uni-lj.si
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu