9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Jacob Moody <moody@mail.posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] private /srv attach option
Date: Mon, 30 May 2022 11:26:35 -0600	[thread overview]
Message-ID: <b3419c6e-04a8-69f0-f7da-badbf0721155@posixcafe.org> (raw)
In-Reply-To: <36C3424BF78FA879D25090315D48F2E1@eigenstate.org>

On 5/30/22 08:44, ori@eigenstate.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.

  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

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3419c6e-04a8-69f0-f7da-badbf0721155@posixcafe.org \
    --to=moody@mail.posixcafe.org \
    --cc=9front@9front.org \


* 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).