Messages in this thread |  | | | Date | Thu, 23 Apr 1998 21:45:22 +0200 | | From | Andrej Presern <> | | Subject | Re: [patch 2.1.97] more capabilities support |
| |
Albert D. Cahalan wrote: > > >> I believe we were discussing POSIX capabilities, not pure capabilities. > >> > >> I'll mail you about the pure capabilities later, but it appears that > >> they are fairly useless outside of an environment like EROS: > >> persistent system image, long-lived processes, NO FILESYSTEM, and > >> every scrap of data is an object associated with some code. > > > > You haven't even looked at the design:) > > I kept asking you for one (in private email)... where is it?
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
|  |