From: ori@eigenstate.org
To: 9front@9front.org
Subject: [9front] RFNOMNT vs unmount
Date: Sun, 20 Dec 2020 11:22:15 -0800 [thread overview]
Message-ID: <2B00BA68FFBEF791E1A7F8173F3F4257@eigenstate.org> (raw)
When trying to restrict a program, it seems common to
bind /path/to/resource over /, and then calling
'rfork m'. This would be reasonably effective in
removing access to resources on the same file server
if it could be made permanent.
Luckily, we have rfork m to prevent new mounts.
Unluckily, rfork m still allows unmounting,
which means that if you mount a constructed
naemspace over /, that can be undone.
This patch disallows unmounting if we've got
RFNOMNT.
diff -r 1ae20c21a286 sys/src/9/port/chan.c
--- a/sys/src/9/port/chan.c Sat Dec 19 19:15:02 2020 +0100
+++ b/sys/src/9/port/chan.c Sun Dec 20 11:14:49 2020 -0800
@@ -790,6 +790,10 @@
wunlock(&pg->ns);
error(Eunmount);
}
+ if(pg->noattach){
+ wunlock(&pg->ns);
+ error(Enoattach);
+ }
wlock(&m->lock);
f = m->mount;
I think it would be nicer if we could make it recursive,
freezing the namespace at 'rfork m', and not allowing
binds or mounts to modify the frozen namespace, but
new namespace operations could be done. The problem
is that MREPL doesn't play well with this.
MREPL replaces a mount point, freeing what's below.
To make MREPL work the way I'd imagine we want, we
need to keep around the old mount, so we can unroll
to the frozen namespace on unmount.
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.
Is this a path we want to go down? It feels a bit more
complex than I like for simply restricting compromised
scripts.
next reply other threads:[~2020-12-20 19:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-20 19:22 ori [this message]
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
2020-12-21 15:34 ` [9front] " Xiao-Yong Jin
2020-12-20 20:33 ori
2020-12-20 21:39 ` cinap_lenrek
2020-12-20 21:52 ` ori
2020-12-21 18:51 ` magma698hfsp273p9f
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=2B00BA68FFBEF791E1A7F8173F3F4257@eigenstate.org \
--to=ori@eigenstate.org \
--cc=9front@9front.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).