From: ori@eigenstate.org
To: ality@pbrane.org
To: 9front@9front.org
Subject: Re: [9front] Re: RFNOMNT vs unmount
Date: Sun, 20 Dec 2020 22:25:14 -0800 [thread overview]
Message-ID: <28EAA3C5D0E2A371721F57EF38F171A4@eigenstate.org> (raw)
In-Reply-To: <X9/jg0G2Am3/KUXx@alice>
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.
next prev parent reply other threads:[~2020-12-21 6:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-20 19:22 [9front] " ori
2020-12-20 19:49 ` hiro
2020-12-20 20:32 ` Steve Simon
2020-12-20 23:51 ` [9front] " Anthony Martin
2020-12-21 6:25 ` ori [this message]
2020-12-21 15:34 ` [9front] " Xiao-Yong Jin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28EAA3C5D0E2A371721F57EF38F171A4@eigenstate.org \
--to=ori@eigenstate.org \
--cc=9front@9front.org \
--cc=ality@pbrane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).