Subject: Re: Hello
From: (Kragen)
Date: Tue, 17 Feb 1998 21:43:04 -0500 (EST)

FSBers: this post contains an interesting assertion about the
limitations of the free-software model, which Cygnus's recent actions
might seem to support.  Comments?

On Thu, 12 Feb 1998, Jonathan S. Shapiro wrote:
> Kragen:
> Thanks for your comments.  Some quick replies on a couple of your
> points.
>    Capability-based systems seem to me to be a much better replacement
>    -- more flexible, faster (since ACLs are slow, and without ACLs,
>    user-based security systems are rather anemic), and they seem to
>    simplify OS design greatly.
> Actually, ACLs would not provide a solution even if they were fast.
> Consider, as an example, that ACLs cannot replace setuid.  You might
> enjoy reading a short note entitled "The Confused Deputy", which you
> can find at

Yes, I read it several days ago.  It covers most of the security
problems reported in the last year on BUGTRAQ.

> The main problem with ACLs is that they defeat delegation.  It is
> impossible for an authorized user (and therefore presumably trusted)
> to give access to a third party.  Setuid is actually a sledgehammer
> applied to the delegation problem.

The other normal solution is to have a daemon running with the
appropriate access.  If I understand correctly, that's how IBM VM
handles setuidish things, right?  Unix systems are doing this more and

> It does not, however, solve the component problem.  A list manager can
> be used to manage a password list or your personal telephone number
> list.  It's probably okay for the telephone number list to have access
> (probably indirect) to the modem to dial for you.  You surely do not
> want the password list manager to have that.  
> Moral: access control wants to be instance-based.


> You might enjoy an introductory essay, entitled "What Is a Capability,
> Anyway?" (  It's
> intended for a lay audience but it describes some interesting
> challenges.

Yes, I read that a few days ago, too :)

>    Is that damn patent going to obstruct EROS?  What's its claimed
>    invention date?  It seems that chroot() covers much the same territory,
>    from a cursory glance at it.
> There is very little relationship between the KeyKOS patent and the
> chroot patent.  EROS has no equivalent to the setuid mechanism, and
> does not need one.

I don't believe chroot is patented, and has nothing to do with setuid.

My understanding of the factory patent is that it covers
a program
	that creates objects
		with a set of capabilities
			that allows them access to the outside world
				only through a guard.

Is that correct?  I haven't read the whole thing.

This is similar to how some programs in UNIX work.

> In any case, I do not expect the patent to be a problem.


>    I'd like to use EROS and promote its use widely.  What kind of
>    licensing are you thinking of using?  You might get more people to help
>    you if you're willing to use an open-source license of some kind.
>    (See
> We will make source code readily available.  It will NOT be generally
> redistributable.  Use of the EROS system for commercial purposes will
> require a license and a reasonable fee.  Personal use, use within
> universities or small non-profits or research institutions will be
> free.  We reserve the right to redistribute and charge for
> modifications that others make.

OK, never mind -- I'm not interested in helping, if what you're after
is making money for yourself off of whatever I contribute, without letting
me make money off of it.

I suspect I'm not in the minority here.

> Pragmatically, this should make EROS free to most of the freeware
> community.  If you go and deploy a business on this we get a cut.  Our
> belief is that this is a reasonable compromise between enabling use
> and not giving away the 40+ staff years of work that have gone in to
> this project so far.

You might consider reading "The Cathedral and the Bazaar", at

I should point out that the author of that paper is a rabid Libertarian
-- one might even say "anarchist", which he does -- and does not
believe people ought to be forced to give their property away.
See, for instance,

> Fortunately, our focal customers are greatly concerned to ensure that
> the version they get is the "official" version, so I don't think there
> is likely to be any serious conflict.

Certainly not between you and them!

> The problem with the free software model, fundamentally, is that it
> doesn't allow for disruptive change.  Basic innovation, in this model,
> can be done only as a labor of love.

I haven't seen any counterexamples.  I have seen disruptive changes --
the 0.67 GIMP was completely incompatible with the current GIMP, and
the change broke all the plug-ins.

I have seen basic innovations come out of the free-software community
-- notably, most of the software that runs the Internet, as well as its
design -- but not nearly as many as I've seen come out of the rest of
the world.  The ones I have seen done have been done as a labor of love,
not in order to provide investors a return on investment.

On the other hand, until about two years ago, there weren't nearly as
many software developers in the free-software community as there were
in the rest of the world.  So we may see some changes here.