I did not get any URL from you. I found the EROS web page myself,
using the altavista.digital.com search engine. I also sent mail
to the author.
> (it's obvious because the page also includes notes on design
> of a UNIX compatible system on top of pure capabilities).
I'm going to substitute the EROS web page for the one you claim
to have told me about: http://www.cis.upenn.edu/~eros/
The EROS web page documents such a thing. It is a hack, and does
not claim to integrate well with the "native" EROS software.
You can emulate Unix on the MacOS too, but it doesn't fit right.
Look, this is seriously alien. It would require a massive kernel
rewrite, most likely with a microkernel design.
>> 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).
Users expect it. Programmers expect it. Admins expect it.
Other systems expect and provide it over NFS, SMB, and NCP.
> 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
So we always run in emulation... that won't do. We need to add
security features that can work well with normal unix software.
Think in terms of _extending_ the current system in compatible ways.
Linux is a real-life OS, not a theoretical OS. There are standards
that we try to comply with, such as Version 2 of the Single Unix
Specification and various BSDisms.
We can have a non-unix environment if there is no other way.
For example, the RT-Linux API is not quite standard. It is not
a problem though, because nobody tries to run the whole system
in that environment. Security needs to be everywhere, not just
for people that can live without unix software.
I know you may be able to give each user their own "unix" to
run in, but that is total isolation. Unix is multi-user.
> 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.
I don't believe this is negotiable. We can't have a barrier between
the POSIX apps and the new apps -- it would be worse than Windows NT.
> 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).
Yes. For people that can spare the swap space, it would be good to
do such a thing _in_ _addition_ to the normal filesystem.
> 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?
We can do that already, by passing file descriptors. It isn't often
done though, because open() is fairly cheap and portable. We don't
have a persistant system image and _can't_ with the way people like
to upgrade the kernel. If you can solve the "upgrade kernel w/o reboot"
problem then you have solved the persistance problem: they are the same.
So far, nobody is close to solving that problem for Linux.
>>>> 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?
You can see the concept by looking at the code. Somebody else just
pointed out that it would be easy to add auditing to the code.
We need that anyway, just to reach C2 AFAIK.
> 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.
After a long private discussion with you, a web search for EROS
and KeyKOS, an email to the EROS author... you should not claim
that I have failed to consider your ideas. I put many hours of
research and thought into the matter.
> 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).
I already did, in private email.
> 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..
Sure, I agree. Please convince me I'm wrong. I really do try to see
this your way, as you can see by the amount of time I put into
learning about EROS and your ideas for Linux.
Have you ever used such a system for real work? If so, describe
what it was like compiling and using standard unix software like
emacs, gcc, tex, bash, and ghostscript. That is, what advantages
did you get while running unix tools? How well did NFS exports work?
Consider the following real-world compromise:
We can implement pure capabilities like Data General does for their
B2 certified DG-UX. They are an "additional access control mechanism"
as defined by Unix98: they can only restrict access. If you want to
use them exclusively, you can "chmod 777" every file after you add
the capability information. This is compatible, safe, and won't
violate the standards.
Standards compliance note: "chmod 000 foo" absolutely must make the
file inaccessable. (must "disable alternate access control")
The opposite need not be true: "chmod 777 foo" might not give
everyone access to the file. (can keep "additional" access control)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu