Re: [9front] [PATCH] private /srv attach option

[Jacob Moody <moody@mail.posixcafe.org>]

On 5/30/22 08:44, ori@eigenstate.org wrote:
> Unfortunately, that doesn't recurse; I can't clear
> out /srv, and add stuff, and let a child clear out
> *its* /srv.
> 

Yes this was a purposeful design decision. If you notice
this code is entirely contained to devsrv itself. If you wanted
'forkable' /srv ala other process groups it only stands to reason
you would add a process group for it and add RF* flags for it.
But I was under the impression that this approach was not desired
or we would have merged in the ANTS work much earlier.

I personally do not see a better way of accomplishing
a 'forkable' /srv without stashing state in to
a process group. I want to avoid that,
and the current implementation reflects that.

> also, maybe it's time to sit down and think about
> where this all goes, rather than tossing random
> diffs over the fence.
>

Now correct me if I am wrong, but I think we tend to like
changes that are made with the implementation in mind.
I "throw a diff over the fence" so I can get an idea of how the
implementation works. I don't like ordaining how something
should work without an idea of how it works currently.

> - What is the current state of locking down... things?

Same as before except we can toss out drivers now.

> - Why is the current state insufficient?

The goal of this patch is to allow a way of keeping the capabilities
that /srv gives, while having it isolated from third parties.
It provides a middle ground between "global" state and "can't
be used at all". I wouldn't call the current state in relation
to this patch 'insufficient', I just think we can do better. Perhaps
we don't need to do better.

> - Are there places where the current state should have
>   been used, but wasn't because of its flaws?

I dont think this question applies? This isn't an iteration
on chdev to hack around an edge case. This is just the idea
that providing the middle ground for /srv as described above could be
desirable.

> - What exactly is the approach to securing things that
>   we're trying to approach?
>

I would like to describe a processes capabilities on the
system as the set of files it has access to. We have a mechanism
for modifying the set of files a process has access to through
namespaces. So it stands to reason that modification of capabilities
should be done through namespace operations. That's the core of my
thoughts.

> A soup of new features of 'rfork M' quality is a problem;
> let's figure out where we're going.
>

Ouch.

For the record I did discuss some of these /srv ideas
in another thread, I believe the it was the one for git/serve to use chdev.
Nobody seemed interested in discussing it then.

But point taken, I wont think about touching code until I fill out
my bikeshedding bingo card first.