From: Jacob Moody <moody@mail.posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] git: use new /dev/drivers for privdrop
Date: Sat, 28 May 2022 19:00:39 -0600 [thread overview]
Message-ID: <696b6b02-135b-f5ba-6903-0a28b3e1b080@posixcafe.org> (raw)
In-Reply-To: <77932a1a-62f8-d7e2-e98b-8da5cea46285@fjrhome.net>
On 5/28/22 18:23, Frank D. Engel, Jr. wrote:
>
> People trying the OS through the type of sandbox test system being
> proposed wouldn't really be able to do anything to test the system if
> they cannot create new processes, but allowing that to go on unchecked
> (without limits) could impact other users.
>
> I tend to agree that if this is a use case to be considered, a quota of
> some kind would be in order.
I dont think this use case is worth perusing. The concept of what constitutes
misuse of a resource is vague and dependent on hardware. Like I mentioned,
I think trying to make the promise that a process with access to a resource
won't misuse it is error prone.
>
> This would also eliminate the need for the somewhat questionable idea of
> using a "fake" device to serve as a process security mechanism for the
> fork call, as one could simply set a quota of zero.
>
>
We are in plan9, a very large chunk of a processes capabilities are accomplished
through access to files. We have a system for mutating a processes view of
files through namespaces.
Devip is also a "fake" device, yet access to that
is tied to the processes ability to talk on the network. It seems consistent
with the theme of the system to describe capabilities as the set of files
a process has access to. If anything the fact that the fork call is a capability
that is not influenced by the namespace makes it the odd one out.
Thanks,
moody
next prev parent reply other threads:[~2022-05-29 1:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-28 16:51 ori
2022-05-28 19:23 ` unobe
2022-05-28 19:41 ` ori
2022-05-28 22:54 ` Jacob Moody
2022-05-29 0:23 ` Frank D. Engel, Jr.
2022-05-29 1:00 ` Jacob Moody [this message]
2022-05-28 21:47 ` covertusername967
2022-05-28 22:07 ` ori
2022-05-28 23:24 ` adr
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=696b6b02-135b-f5ba-6903-0a28b3e1b080@posixcafe.org \
--to=moody@mail.posixcafe.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).