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=3.6 required=5.0 tests=RCVD_IN_SBL_CSS autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 29631 invoked from network); 22 Jan 2021 00:08:10 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 22 Jan 2021 00:08:10 -0000 Received: from 5ess.inri.net ([107.191.111.177]) by 1ess; Thu Jan 21 18:44:20 -0500 2021 Received: from [127.0.0.1] ([166.170.220.211]) by 5ess; Thu Jan 21 18:44:20 -0500 2021 Date: Thu, 21 Jan 2021 18:44:18 -0500 From: Stanley Lieber To: 9front@9front.org In-Reply-To: References: <154A2B81E5307985989F46BE958ACBAC@eigenstate.org> <84C199F8-15A4-4434-AD56-A35AB5CC6F4A@stanleylieber.com> Message-ID: 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: managed module-oriented general-purpose-aware AJAX over YAML event pipelining interface Subject: Re: [9front] user none: cwfs vs hjfs Reply-To: 9front@9front.org Precedence: bulk On January 21, 2021 5:55:00 PM EST, hiro <23hiro@gmail=2Ecom> wrote: >if multiple users need to keep state that is supposed to be separated >and private, then those users need to authenticate in a reliable way=2E > >for this we have dp9ik, and fileservers can do user-level and even >group-level separation, so that state can be kept by a single and not >1 fileserver per user=2E > >On 1/21/21, hiro <23hiro@gmail=2Ecom> wrote: >> why do you think running every service as none is a recommended practic= e? >> >> On 1/21/21, Stanley Lieber wrote: >>> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail=2Ecom> wrote: >>>>otoh not fixing hjfs may break security assumptions=2E >>>> >>> >>> yes=2E i think we should fix hjfs=2E a lot of stuff relies on user non= e doing >>> what it does in cwfs=2E the most import thing is that all file systems >>> behave >>> the same way=2E >>> >>> that said, relegating user none to world readable files while >>> simultaneously >>> running basically every service as none makes isolating services, and >>> more >>> blatantly keeping local users out of service files, difficult if not >>> impossible=2E >>> >>> i think they got lazy with user none=2E we need some finer grade contr= ol >>> over >>> user capabilities=2E >>> >>> sl >>> >> > do you seriously not follow what i'm saying here or are you just trying to= map out a solution? user none masks the special # file system, but (once we fix hjfs) requires= world accessible files=2E this means any user on the file system can also = access those files unless special steps are taken to prevent it=2E for exam= ple, upas becomes user none to process files through /mail/queue no matter = who upas starts out running as=2E the default listener runs as none and sca= ns the service directory=2E any user on the file system (including none) mu= st be trusted with any file none can access=2E there's a basic conflict her= e that has no current solution except "run everything that requires file pr= ivacy on separate file systems=2E" regular users honor finer grained file permissions, but cannot be masked f= rom the special # file system=2E there is a basic conflict here that has no= solution at all=2E any regular user must be trusted with proc, binding, un= binding, this is why user none exists in the first place=2E the disconnect here is between file and process permissions=2E they are co= mpletely different things=2E we have fine grained file permissions but auth= is all or nothing=2E sl