Re: ports suggestion

[Niels Möller]

"Richard A. Kelley, Jr." <address@hidden> writes:

> Let us say, for purposes of illustration that the
> virtual kernel is initially called "v-L4".  As has
> already been pointed out, the L4 does not use a
> port as a communication channel which was a
> fundamental part of Mach and based on my
> understanding, it is a fundamental part of the
> design of hurd.  So, the v-L4 code wise could be a
> mix of the current L4 and the parts of the Mach
> that kernel wise are most important to the hurd. 
> The implimentation of a port on the L4 would then
> become the responsiblity of those developing the
> v-L4.

I believe that is the current plan. The "virtual something" have been
discussed for a long time (and on this list since it was started some
months ago), one of the names for it is "libmom".

> The security issues presented relative to how
> ports might be handled concerned me.  This may be
> based on my ignorance, but a process should not
> have a changeable uid.

Then you get into difficulties when implementing basic programs like
"login" or "su". Even if most processes never change uid, that feature
have to be taken into account. And on the Hurd, a process can even
have *several* uids at the same time.

> A text editor by default would have no rights. 
> When I as a user access the text editor, there
> would be a certain level of rights transferal, but
> even at this point, the text editor should still
> retain it's same uid.  Furthermore, just because I
> have read write access to my home directory and
> all sub content, it does not mean that by default
> I would want a text editor accessing my home
> directory to have all those same rights.

I disagree. By default, if I tell my text editor to open
"~/my/private/file", and I have the rights to read that file, I want
the text editor to just open it. I don't want to have to answer any
questions or type any extra passwords just to do that. So the editor
would have all the rights I have.

Being able to run a process in a limited sandbox would be useful, but
I don't think you want to sandbox basic things like your login shell
or text editor.

When thinking of it, it might make more sense to sandbox "viewer-type"
programs, that operate only on one file which is known in advance. I'm
not sure how to do that on hurd, but perhaps something like

  su --no-uids visual-basic-interpreter < fishy-vb attachment

could be used to run the interpreter in an environment where it has
(read-only) access to my file on stdin, and to files accessible to
no-uid processes (which would include read only access to any run-time
support files). It's still tricky to give it access to my tty or
window-system in a safe way, I guess.

(And yes, I'm told that Miguel de Icaza is actually working on a free
visual basic interpreter, primarily for exc*l-compatibility in
gnumeric. *shiver*).

/Niels