Re: [9fans] capability-based design (Re: permissions idea)

Re: [9fans] capability-based design (Re: permissions idea)

[okamoto]

What is major difference between Amoeba and EROS?

Kenji

Re: [9fans] capability-based design (Re: permissions idea)

[Maarit Maliniemi]

(A copy of this message has also been posted to the following newsgroups:
comp.os.plan9)

In article <20011005035913.A10F919A29@mail.cse.psu.edu>, 9fans@cse.psu.edu
wrote:

> What is major difference between Amoeba and EROS?
> 
> Kenji

EROS is persistant.

bengt

Re: [9fans] capability-based design (Re: permissions idea)

[okamoto]

>Yep, PHOBOS would be better :-)

There must be Damos, too...

Re: [9fans] capability-based design (Re: permissions idea)

[Lucio De Re]

On Mon, Oct 08, 2001 at 02:16:43PM -0400, Sape Mullender wrote:
> > 
> > EROS is persistant.
> 
> Which makes a EROS a poor choice of name.

Yep, PHOBOS would be better :-)

++L

Re: [9fans] capability-based design (Re: permissions idea)

[Sape Mullender]

> > What is major difference between Amoeba and EROS?
> > 
> > Kenji
> 
> EROS is persistant.

Which makes a EROS a poor choice of name.

Re: [9fans] capability-based design (Re: permissions idea)

[Thomas Bushnell, BSG]

greon@best.com (Richard) writes:

> it must be frustrating to have written software for one of those
> once-popular platforms only to see the owner of the platform let it die.
> I speculate that proprietary OSes need to attract 10s of millions of
> users or their owners let them die, but that open source OSes can
> survive for decades with much fewer users.

Free software operating systems have an automatic edge because they
don't rely on the continued interest of their original authors.

Re: [9fans] capability-based design (Re: permissions idea)

[Russ Cox]

> And it is important: it is kind of sterile to develop something as
> labor-intensive as an OS without knowing anything about the economic
> forces that determine how popular the thing will become.

Only if popularity is the primary goal.  All things being equal,
maybe I'd like there to be more Plan 9 users.  But all things
are not equal.  Given the choice between a simple and consistent
system like Plan 9 or a popular system like Windows or Linux,
I'll take Plan 9.

Russ

Re: [9fans] capability-based design (Re: permissions idea)

[Richard]

nigel@9fs.org writes:
>This is a multi-part message in MIME format.
>--upas-vfwrimsfaddulhvxlwqtwrsphv
>Content-Disposition: inline
>Content-Type: text/plain; charset="US-ASCII"
>Content-Transfer-Encoding: 7bit
>
>>> the success rate compared with
>>> proprietary OSes is rather good.  note that almost all proprietary
>>> OSes have educated and experienced designers and implementors.
>>>
>I've a feeling that for every GPL'ed OS you can name which is successful,
>I can name several non-GPL'ed ones. In fact, I can only think of one
>successful GPLed OS...

Right, but my argument is as follows.

EROS has an educated, experienced writer.  Thus, to understand
EROS's chances of becoming popular, we can ignore OSes written by,
eg, arrogant teenage boys.

There have been many hundreds of proprietary OSes written last 30 years
(more in the early part of that period, since markets have
consolidated).  Just proprietary forks off of BSD there might have been
as many as 100.  Then there's dozens of OSes that came out of the PC
revolution of 1976-1983.  Most have educated, experienced writers (ok,
not the early PC OSes, but the others).  100s have had development
budgets in the millions (again, mostly during the early half of the
period).  OS/2's development budget was 3 billion.

The amount of development effort, measured in man hours times
competence, say, that has gone into proprietary OSes is much greater
than the amount that has gone into GPLed OSes.

Of course there has been only one very successful GPLed OS.  But it is
pretty clear from reading the Linux kernel developers that being GPLed
is a large part of the reason for Linux's success, rather than being a
coincidence.

(BSD is generally regarded as better stuff than Linux but has no more
than a fifth of Linux's users and developers.  That is why I talk
about GPLed rather than just open-sourced software.)

Since 99% of users and 99% of application development is targeted at
the top 3 or 4 platforms, Linux alone is probably the target of a good
15-20% of all application development effort. 

So, I conclude that a given unit of OS development effort will tend to
yield greater expected number of users and applications developers and
greater expected lifetime if the OS is GPLed than if it is proprietary
--when we restrict ourselves to OSes with educated experienced writers.

This same analysis does not apply to all categories of software because
OSes are subject to unusually fierce network effects.  But programming
languages and their implementations have strong network effects, too,
and there the performance of open-source (non GPL this time) offerings
(measured by number of users times expected longevity) is also
impressive.  eg, Perl, Python, Ruby and Caml users do not lack for
useful libraries and ports to various platforms and need not fear their
language dying out any time soon.  At least the first two languages in
sophisticated markets like Silicon Valley, employers do not fear not
being able to find programmers experienced in the language

I've left many important facts out of my argument, and the argument is
imprecise and uncertain, but sometimes vague is the best you can do.
And it is important: it is kind of sterile to develop something as
labor-intensive as an OS without knowing anything about the economic
forces that determine how popular the thing will become.

Richard

Re: [9fans] capability-based design (Re: permissions idea)

[nigel]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

>> the success rate compared with
>> proprietary OSes is rather good.  note that almost all proprietary
>> OSes have educated and experienced designers and implementors.
>>
I've a feeling that for every GPL'ed OS you can name which is successful,
I can name several non-GPL'ed ones. In fact, I can only think of one
successful GPLed OS...


[-- Attachment #2: Type: message/rfc822, Size: 2731 bytes --]

From: Richard <greon@best.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] capability-based design (Re: permissions idea)
Date: Fri, 05 Oct 2001 00:40:45 -0700
Message-ID: <E15pPbB-0002yN-00@localhost>

nigel@9fs.org writes:

>>> also, EROS's GPLed.  I do not say that is an improvement, but 
>>> a GPLed OS has done very well lately in popularity.
>
>This is a bit self-fulfilling isn't it? How many GPL'ed OSes are there
>thay haven't become popular? We don't know, because they haven't
>become popular enough to get publicised.

there are many GPLed OSes, but most are written by teenagers or young
men with little education or experience.  among GPLed OSes with
competent designers and implementors, the success rate compared with
proprietary OSes is rather good.  note that almost all proprietary
OSes have educated and experienced designers and implementors.

I am thinking also about the abandonment of AmigaOS, OS/2 and (probably)
BeOS.  it must be frustrating to have written software for one of those
once-popular platforms only to see the owner of the platform let it die.
I speculate that proprietary OSes need to attract 10s of millions of
users or their owners let them die, but that open source OSes can
survive for decades with much fewer users.

the "fitness landscape" for OSes is quite harsh and severe because
of numerous "network effects".  "network effect" is a term from
economics that every computerist should understand.

Re: [9fans] capability-based design (Re: permissions idea)

[Richard]

nigel@9fs.org writes:

>>> also, EROS's GPLed.  I do not say that is an improvement, but 
>>> a GPLed OS has done very well lately in popularity.
>
>This is a bit self-fulfilling isn't it? How many GPL'ed OSes are there
>thay haven't become popular? We don't know, because they haven't
>become popular enough to get publicised.

there are many GPLed OSes, but most are written by teenagers or young
men with little education or experience.  among GPLed OSes with
competent designers and implementors, the success rate compared with
proprietary OSes is rather good.  note that almost all proprietary
OSes have educated and experienced designers and implementors.

I am thinking also about the abandonment of AmigaOS, OS/2 and (probably)
BeOS.  it must be frustrating to have written software for one of those
once-popular platforms only to see the owner of the platform let it die.
I speculate that proprietary OSes need to attract 10s of millions of
users or their owners let them die, but that open source OSes can
survive for decades with much fewer users.

the "fitness landscape" for OSes is quite harsh and severe because
of numerous "network effects".  "network effect" is a term from
economics that every computerist should understand.

Re: [9fans] capability-based design (Re: permissions idea)

[nigel]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

>> also, EROS's GPLed.  I do not say that is an improvement, but 
>> a GPLed OS has done very well lately in popularity.

This is a bit self-fulfilling isn't it? How many GPL'ed OSes are there
thay haven't become popular? We don't know, because they haven't
become popular enough to get publicised.

I'm off to look for elephants with red toenails in cherry trees.


[-- Attachment #2: Type: message/rfc822, Size: 1893 bytes --]

From: Richard <greon@best.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] capability-based design (Re: permissions idea)
Date: Thu, 04 Oct 2001 16:57:15 -0700
Message-ID: <E15pJvL-0002PD-00@localhost>

forsyth@caldo.demon.co.uk writes:
>in what way(s) do "capa" and eros improve on
>(say) CAP or ten15?

let me append to my response.

past capa systems suffered from poor performance, I understand.  EROS's
designer thinks he can solve that problem, so that EROS's performance on
common tasks will approximate that of mainstream OSes.  I do not
understand most of what this guy says.  

also, EROS's GPLed.  I do not say that is an improvement, but 
a GPLed OS has done very well lately in popularity.

Re: [9fans] capability-based design (Re: permissions idea)

[Richard]

forsyth@caldo.demon.co.uk writes:
>in what way(s) do "capa" and eros improve on
>(say) CAP or ten15?

let me append to my response.

past capa systems suffered from poor performance, I understand.  EROS's
designer thinks he can solve that problem, so that EROS's performance on
common tasks will approximate that of mainstream OSes.  I do not
understand most of what this guy says.  

also, EROS's GPLed.  I do not say that is an improvement, but 
a GPLed OS has done very well lately in popularity.

Re: [9fans] capability-based design (Re: permissions idea)

[Richard]

forsyth@caldo.demon.co.uk writes:
>in what way(s) do "capa" and eros improve on
>(say) CAP or ten15?

I do not know.  a google search on cap ten15 yields
nothing immediately informative.  since capability-based
OSes have been around since the 70s, I'm guessing they
are capability-based OSes or programming environments.

I used "capa" as short for "capability-based".

Re: [9fans] capability-based design (Re: permissions idea)

[forsyth]

in what way(s) do "capa" and eros improve on
(say) CAP or ten15?

Re: [9fans] capability-based design (Re: permissions idea)

[Richard]

I just wrote: "an open file descriptor is very much like a capability
that cannot be forged."

I meant: "an open file descriptor that cannot be forged is very much like a
capability."

Re: [9fans] capability-based design (Re: permissions idea)

[Richard]

rog@vitanuova.com writes:
>> the app must asks permission (from the OS, which
>> then might ask the user) before doing anything significant to the user's
>> software environment. 
>
>surely that assumes that the user wouldn't just automatically accept
>any reasonable-sounding request to open a file (i know i would,
>especially if i had several hundred per day).

the user does not have to do it explicitly, he can have programs
dispense permission on his behalf.  the user can write these programs
or they can be provided by whoever provides his software.

so for example, the program that installs your email client would ask
you for permission to create a file to archive mail in.  actually it
would call a file-creation primitive, which would ask you.  the creation
primitive would return a file descriptor to the installer, which could
do whatever it wanted with the descriptor.  a sensible thing to do would
be to give it to the email client "factory".  the email client factory
is the program that can start instances of the actual email client.
(think of an app's icon on a Windows desktop.)  the email client factory
would in turn give the file descriptor to the email clients processes it
creates, so that the process need not bother the user with mention of
the archive file.

so, after installation, the software environment need never 
ask the user for permission to open the archive file.

now on Plan 9 and Unix, open file descriptors cannot survive a reboot.
a capa OS would need to provide for their survival somehow.  eg, EROS
and KeyKOS (proprietary OS mired in intellectual-property hell which is
the main inspiration for EROS) have persistent processes that can
survive reboot.  (and their data of course survives with them.)
the reason they made that design decision is that most of the
opportunity for inadvertently creating security holes in a capa
software environment occurs during setting things up and starting
things up.

I have been talking about file descriptors, but I really mean
capabilities.  an open file descriptor is very much like a capability
that cannot be forged.  an unforgable pointer to an object (thing with
state and methods) is also essentially a capability, if you prefer OO
thinking over 9ish file thinking.

>capabilities (and ACLs) seem to me like they'd be a maintenance
>nightmare. i can barely remember to chmod my personal files 600...

again, a software environment suited to a user 
needs to ask the user for permission only when the user wants to do
things differently from what was decided by whoever provided his
software.  eg,  nothing in a capability-based software environment is
inconsistent with a docile user who knows nothing about security where
all security policies have been decided by the "vendor" or (Linux
terminology) "distribution maintainer".

Re: [9fans] capability-based design (Re: permissions idea)

[rog]

> the app must asks permission (from the OS, which
> then might ask the user) before doing anything significant to the user's
> software environment. 

surely that assumes that the user wouldn't just automatically accept
any reasonable-sounding request to open a file (i know i would,
especially if i had several hundred per day).

might it not be better just to use filterfs to make sure that an
application can't see the files i want to hide from it?  you could
even add an interface so that an application could request that a
certain file/filetree be made visible; that could even trigger a
request to the user if required.

capabilities (and ACLs) seem to me like they'd be a maintenance
nightmare. i can barely remember to chmod my personal files 600...

  rog.

[9fans] capability-based design (Re: permissions idea)

[Richard]

Douglas A. Gwyn writes:

>  The only
>viable solution I know of is for *every* mode of access
>to *every* object to require the accessor to possess an
>appropriate "capability".

word.  let me give the reader a little taste of capability-based
design, for those who might not know it.  In a capability-based OS, a
program does not have free access to the filesystem.

suppose that in Plan 9 the shell and the rm command were rewritten so
that in the execution of the command

  rm foobar

the shell opened the file foobar and passed the open file descriptor to
rm.  (this would of course mean expanding the argc/argv interface so
that not only strings but also file descriptors can be passed in.)
suppose further that all commands worked this way, and that the OS
prevented commands (programs) from directly opening files.  well, more
precisely, suppose that the open subroutine would obtain the user's
permission before opening the file.

in such an OS, a command cannot modify the filesystem behind the user's
back.  in contrast, in Unix and Plan 9, a command written by a malicious
programmer can, eg, erase or introduce errors into a user's data files.

the risk of inadvertently running a malicious program is not a big
problem in practice for many of us, so the reader might not be attracted
to the idea of changing things just to avert that risk.  note though
that the capability ("capa") design averts the risk without adding a lot
of new code (as the stupid idea of digital immune systems does), but
rather mainly by readjusting the interface between shell and command.
elegant!

a more practical benefit of the capa approach that might appeal more to
the average desktop user is the discipline it imposes on app writers.
specifically, the app must asks permission (from the OS, which
then might ask the user) before doing anything significant to the user's
software environment.  

eg, if a community of users got into the habit, for example, of guarding
the ability to display animated graphics behind a capability, then an
app writer who wanted to distribute an app into that community would
have to write code that explicitly asks permission to display
animations, even if the app already had permission to write static
graphics to the screen.

another, classic example is that if you install Internet Explorer on
Windows, it or its installer is free to fuck up your already-installed
Netscape.  in a capa OS, the IE installer cannot make IE your default
browser without obtaining permission.  this restriction is enforced by
the kernel just like the restriction that the IE installer cannot access
memory belonging to another process.

a typical desktop computer is used by only one person but contains apps
written by thousands of programmers.  if you are like me, you would like
app writers to have less power over the other apps on your desktop and to
make fewer assumptions about your software environment.  this of course,
takes us outside of security per se, into the realm of giving users
more control over apps, not by exhorting app writers to change, but
by introducing a new platform that forces them to change or else
their code does not run.