Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff

[olafBuddenhagen]

Hi,

On Tue, Dec 30, 2008 at 12:10:39PM +0100, Michal Suchanek wrote:
> On 27/12/2008, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net>
> wrote:

> >  The user session is obviously not the parent of all processes --
> >  that just wouldn't work in a multi-user system. But all processes
> >  *of the same user* are descendants of the user session.
> >
> >  Now in Coyotos this doesn't mean much, as the parent doesn't
> >  directly create a process, but rather just invokes the constructor.
> >  This way the child process can have authority that the parent
> >  process doesn't have. And the spacebank mechanism ensures that even
> >  though the resources are usually supplied by the parent, it still
> >  has no access to the child's memory contents.
> >
> >  In the hierarchical system we proposed the situation is very
> >  different however. Processes are created directly by the parent, so
> >  they can't have any additional authority; and the process handing
> >  out memory always has full access to it. The user session has full
> >  control over all its descendants, and thus all the user's
> >  processes.
> 
> This system differs from coyotos in that the processes are really
> started by their parent, not a system service. That does not seem that
> different to me.
> 
> In coyotos the tree is very flat, pretty much everything is descendant
> of some 'constructor service' but the concept is the same I would
> think.

The flat hierarchy is precisely the difference. The constructor
mechanism allows a process to have authority that the process starting
it doesn't have. The space bank allows the process to use memory not
accesible by the process who provides the memory (which is usually also
the one which started it). Together, these mechanisms allow any process
to hide things from the processes which started it. (And thus from the
user running a program.)

This is not an accident. EROS/Coyotos are explicitely designed for that.
And this is what we take issue with.

> > I don't know much about SElinux etc. However, AFAIK they only limit
> > the power of the traditional root account, but *not* the power of
> > the actual admin.
> 
> Since 'root' is the 'administrative account' this is pretty much the
> same thing.

No it's not. root is used for a lot of non-administrative tasks in a
traditional UNIX system -- many services run as root. Which is precisely
why it is exposed to exploits so much.

> If you cannot do something as root you cannot do it at all on the
> system

This is just wrong. Think of BSD secure levels for example: Certain
things are protected when the system is running in the normal mode, but
the administrator can still change them by starting it in a different
secure level.

SElinux does it differently AFAIK, but I'm pretty sure the effect is
similar.

> >  Coyotos on the other hand is designed in such a fashion that once
> >  the system is installed, nobody -- not even the admin -- has full
> >  control over all parts of it.
> 
> As I understand it it's one of the possible configurations.
> 
> You could install a configuration with a 'root' account which would be
> certainly useful for debugging or single user systems.

I doubt that, considering Shapiro's stance on this...

Anyways, as I already said, this is rather beside the point.

> >  Obviously appliactions need to be protected against harmful
> >  interference. However, that does *not* mean total isolation. They
> >  still can, and should, uses common mechanisms, common interfaces,
> >  common services -- integration between different applications is a
> >  must. And this is just not realistic if different applications run
> >  in completely different environments. Only applications using more
> >  or less the same personality can be properly integrated; and if we
> >  care about POSIX applications -- which we do -- this personality
> >  must be based on POSIX.
> >
> 
> I am not so sure about that. For example Compozer is available for
> both Windows and Linux, and the Linux version crashes on my system so
> I run the Windows version inside Wine.
> 
> The underlying interface the two binaries use is different. However,
> they both show a window on my screen and access the same Documents
> folder for opening and saving files. This is all the compatibility one
> ever needs for a typical application.

No, this is all that *you* seem to be interested in. Other people expect
better integration between applications -- there is a reason things like
dbus were created.

Also note that integration between GNU/Linux and Windows is realatively
easy, as NT is a UNIX-like system for the most part. It would be *much*
harder between UNIX applications and Coyotos applications. Let's take
the documents folder: Coyotos doesn't have a UNIX-like filesystem for
starters, so this wouldn't work without adaptation.

> On 30/12/2008, Arne Babenhauserheide <arne_bab@web.de> wrote:
> > Am Dienstag 30 Dezember 2008 12:10:39 schrieb Michal Suchanek:

> > What about dbus?
> >
> >  Most of my typical applications use it for communication.
> 
> I am not sure how exactly dbus works. I have some vague idea that
> applications connect to it through a unix socket through which they
> can send or receive messages.
> 
> If you really want that you can probably mount the socket to the
> environment of any application that would use it.

You are missing the point: There would still be no integration between
applications running in the UNIX environment, with dbus and all, and
"native" applications running in an environment knowing nothing about
dbus.

dbus is just an example; the same problem arises with *any* interface
that can't be mapped 1:1 to the "native" one.

-antrik-