From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14206 invoked from network); 30 May 2022 17:29:07 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 30 May 2022 17:29:07 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Mon May 30 13:27:01 -0400 2022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1653931617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JG3yl/jQXt/qiSH2dAghPDrd2t0OfIiT3ahf4hQSd8Y=; b=olWTNdB3ZiXDDmtodxsSQFVsIY+k7Kt0nXiV33CVR+QyDifixtNcQhL2OsTttjVHdlRnSf gfwv3Fibtew+vVgZeZ666AsrbQC9ra3FdWXLKVYJhZEf/n1wi2J8oMaYqd4kFb/qIMyCHr XSwx0RCTwLZyLrPu0DN+eZZAui8iumU= Received: from [192.168.168.200] (161-97-228-135.lpcnextlight.net [161.97.228.135]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id ed271135 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Mon, 30 May 2022 12:26:57 -0500 (CDT) Message-ID: Date: Mon, 30 May 2022 11:26:35 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: 9front@9front.org References: <36C3424BF78FA879D25090315D48F2E1@eigenstate.org> From: Jacob Moody In-Reply-To: <36C3424BF78FA879D25090315D48F2E1@eigenstate.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: content-driven proxy-oriented backend Subject: Re: [9front] [PATCH] private /srv attach option Reply-To: 9front@9front.org Precedence: bulk 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 desirable. > - 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 thoughts. > A soup of new features of 'rfork M' quality is a problem; > let's figure out where we're going. > Ouch. 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.