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=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4989 invoked from network); 22 Jan 2021 15:20:28 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 22 Jan 2021 15:20:28 -0000 Received: from 5ess.inri.net ([107.191.111.177]) by 1ess; Fri Jan 22 09:51:50 -0500 2021 Received: from [127.0.0.1] ([104.59.85.219]) by 5ess; Fri Jan 22 09:51:47 -0500 2021 Date: Fri, 22 Jan 2021 09:51:41 -0500 From: Stanley Lieber To: 9front@9front.org In-Reply-To: References: <154A2B81E5307985989F46BE958ACBAC@eigenstate.org> <84C199F8-15A4-4434-AD56-A35AB5CC6F4A@stanleylieber.com> Message-ID: <7AF49F1D-0B66-4C09-B7BA-32FB34872CAF@stanleylieber.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: optimized proven event lifecycle controller Subject: Re: [9front] user none: cwfs vs hjfs Reply-To: 9front@9front.org Precedence: bulk On January 22, 2021 4:14:24 AM EST, hiro <23hiro@gmail=2Ecom> wrote: >> do you seriously not follow what i'm saying here or are you just trying= to >> map out a solution? > >i was trying to imagine out loud how the existing security >architecture could be utilized as fully as possible=2E > >i am not saying it is the best solution, just trying to stay on the >track that the bell-labs people have laid out=2E > >i am not saying we didn't break it=2E but if we know the intent of the >basic architecture we might be able to fix it without creating a >second system=2E > yeah, i'm with you there=2E i really think they just tried to sidestep thi= s whole issue by stipulating anyone with fs access was trusted=2E remember = the "joke" about securing the fs by locking the server room door? sl