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=RCVD_IN_DNSWL_NONE
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 23836 invoked from network); 21 Dec 2020 06:27:33 -0000
Received: from ewsd.inri.net (107.191.116.128)
  by inbox.vuxu.org with ESMTPUTF8; 21 Dec 2020 06:27:33 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Mon Dec 21 01:25:25 -0500 2020
Received: from abbatoir.fios-router.home (pool-74-101-2-6.nycmny.fios.verizon.net [74.101.2.6])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id f13c8680 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO);
	Sun, 20 Dec 2020 22:25:16 -0800 (PST)
Message-ID: <28EAA3C5D0E2A371721F57EF38F171A4@eigenstate.org>
To: ality@pbrane.org
To: 9front@9front.org
Date: Sun, 20 Dec 2020 22:25:14 -0800
From: ori@eigenstate.org
In-Reply-To: <X9/jg0G2Am3/KUXx@alice>
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: ISO-certified software engine 
Subject: Re: [9front] Re: RFNOMNT vs unmount
Reply-To: 9front@9front.org
Precedence: bulk

Quoth Anthony Martin <ality@pbrane.org>:
> > This can be done by treating cmount() almost like a union,
> > but putting a flag within the union so that names() stops
> > traversing the union early -- 'm->shadow'; unmount can
> > then prune just the mounts with an newer 'freeze depth'
> > than the current rfork depth.
> 
> You should make the change in your own kernel if you
> have a need for it. Then, after a few weeks or more,
> let us know what the consequences were. At that point
> we can have a better discussion.

The patch I posted in the initial email covers my needs,
and I'll be running it. But there's not much to be learned
from how it interacts with the system, though, because very
little within the system uses RFNOMNT.

For good reason. As hiro pointed out, it's not particularly
well designed. I'd be happy to implement a more general and
more useful solution, but I don't have ideas I'm happy with
right now.

My goal is to restrict the impact of a compromised process;
for example, if I were inappropriately escaping paths in
shithub, and someone were able to inject a shell command,
I would like the viewer to be unable to access the user
home directories.