From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 1798 invoked from network); 30 May 2022 20:06:57 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 30 May 2022 20:06:57 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Mon May 30 16:04:29 -0400 2022
Received: from stockyard (cpe-68-174-86-38.nyc.res.rr.com [68.174.86.38])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 716fb59b (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Mon, 30 May 2022 13:04:18 -0700 (PDT)
Message-ID: <847F45EC7225C1D0B69E796B69D6E3ED@eigenstate.org>
To: 9front@9front.org
Date: Mon, 30 May 2022 16:04:15 -0400
From: ori@eigenstate.org
In-Reply-To: <b3419c6e-04a8-69f0-f7da-badbf0721155@posixcafe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: converged engine SSL over JSON browser descriptor factory cloud 
Subject: Re: [9front] [PATCH] private /srv attach option
Reply-To: 9front@9front.org
Precedence: bulk

Quoth Jacob Moody <moody@mail.posixcafe.org>:
> 
> > 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.
> 

in isolation, this change seems.. fine, I guess. It does
something useful, though it's got some inelegance around
needing a global view to get a clean /srv, which means
that a restricted /srv can't get a clean /srv. It's also
encoded into the interface, so we can't easily fix it
later.

This may or may not matter, I don't know.

the gripe I have is that I know you're aiming turn namespaces
into useful security boundaries, as well as providing other
ways to ratchet down permissions. But I haven't seen a summary
of the changes you feel are needed, the places and ways that
they'd be used, and a diversity of examples that demonstrate
the changes are parsimonious and sufficient.

What is the end goal, and what should it be?

Let's not design in a vaccuum.