[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Niches for the Hurd: evaluation method; was: DRM musings, capabiliti

From: Michal Suchanek
Subject: Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff
Date: Wed, 31 Dec 2008 14:35:46 +0100

On 31/12/2008, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net> wrote:
> 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.

This is completely beside the point as well.

If you want a POSIX system Coyotos is completely out of question.

I would think that the kernel itself does not provide the constructor
primitive - I would make it a service on top of a simple kernel.

But there was some other reason why the Coyotos kernel would not work
as a base for the Hurd so there is no point in discussing how
'drm-ridden' it is.

Yes, the system provides a service out of the box that provides DRM
memory which might be a step towards DRM content protection. I do not
like the feature but I have not seen a secure system design without
such feature, either. So it might be a requirement for a robust system
because I do not see how you can get robustness without security.

>  > > 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.

You can shut down Coyotos and look at the on-disk image. As going to
less secure level from a more secure level can be only done by
rebooting there is not much difference here.

>  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.

I do not know why dbus was created and what problems it is trying to
solve. And I have no idea why a word processor would need to
communicate with any other application for example. There are
clipboards but these are not in dbus so I really don't know any use
case for typical application communicating through dbus with another

>  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.

How so? It has generic objects but to find the objects in the system
you need some sort of object directories (or more precisely capability
directories). This is very similar to the unix hierarchical filesystem
structure. Not every capability needs to reference something that
behaves like a plain file or directory but this is not unlike unix
pipes and devices, Hurd translators, etc.

>  > 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.

Why so?

dbus uses streams for communication, and there sure is need for
streams in any system. I do not see how this does not fit.

I would want to examine dbus and see if it can be modified to make
better use of the system or if it just tries to work around some
problems that could be solved differently on non-unix system but for
start there is no reason why its socket cannot be used by any



reply via email to

[Prev in Thread] Current Thread [Next in Thread]