From: Jacob Moody <firstname.lastname@example.org>
Subject: Re: [9front] [PATCH] private /srv attach option
Date: Mon, 30 May 2022 11:26:35 -0600 [thread overview]
Message-ID: <email@example.com> (raw)
On 5/30/22 08:44, firstname.lastname@example.org wrote:
> Unfortunately, that doesn't recurse; I can't clear
> out /srv, and add stuff, and let a child clear out
> *its* /srv.
Yes this was a purposeful design decision. If you notice
this code is entirely contained to devsrv itself. If you wanted
'forkable' /srv ala other process groups it only stands to reason
you would add a process group for it and add RF* flags for it.
But I was under the impression that this approach was not desired
or we would have merged in the ANTS work much earlier.
I personally do not see a better way of accomplishing
a 'forkable' /srv without stashing state in to
a process group. I want to avoid that,
and the current implementation reflects that.
> also, maybe it's time to sit down and think about
> where this all goes, rather than tossing random
> diffs over the fence.
Now correct me if I am wrong, but I think we tend to like
changes that are made with the implementation in mind.
I "throw a diff over the fence" so I can get an idea of how the
implementation works. I don't like ordaining how something
should work without an idea of how it works currently.
> - What is the current state of locking down... things?
Same as before except we can toss out drivers now.
> - Why is the current state insufficient?
The goal of this patch is to allow a way of keeping the capabilities
that /srv gives, while having it isolated from third parties.
It provides a middle ground between "global" state and "can't
be used at all". I wouldn't call the current state in relation
to this patch 'insufficient', I just think we can do better. Perhaps
we don't need to do better.
> - Are there places where the current state should have
> been used, but wasn't because of its flaws?
I dont think this question applies? This isn't an iteration
on chdev to hack around an edge case. This is just the idea
that providing the middle ground for /srv as described above could be
> - What exactly is the approach to securing things that
> we're trying to approach?
I would like to describe a processes capabilities on the
system as the set of files it has access to. We have a mechanism
for modifying the set of files a process has access to through
namespaces. So it stands to reason that modification of capabilities
should be done through namespace operations. That's the core of my
> A soup of new features of 'rfork M' quality is a problem;
> let's figure out where we're going.
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.
But point taken, I wont think about touching code until I fill out
my bikeshedding bingo card first.
next prev parent reply other threads:[~2022-05-30 17:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-30 11:50 Jacob Moody
2022-05-30 14:44 ` ori
2022-05-30 17:26 ` Jacob Moody [this message]
2022-05-30 20:04 ` ori
2022-05-31 7:03 ` hiro
2022-05-31 15:09 ` Jacob Moody
2022-05-31 16:04 ` Jacob Moody
2022-06-08 14:48 ` Jacob Moody
2022-06-22 15:22 ` cinap_lenrek
2022-05-30 14:56 ` ori
2022-07-10 21:47 ` ori
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).