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 4984 invoked from network); 22 Jan 2021 01:19:24 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 22 Jan 2021 01:19:24 -0000 Received: from 5ess.inri.net ([107.191.111.177]) by 1ess; Thu Jan 21 19:53:06 -0500 2021 Received: from [127.0.0.1] ([166.170.220.211]) by 5ess; Thu Jan 21 19:53:06 -0500 2021 Date: Thu, 21 Jan 2021 19:53:04 -0500 From: Stanley Lieber To: 9front@9front.org In-Reply-To: <8810E8F846CEF25EEA2C33E9D750FA3D@eigenstate.org> References: <8810E8F846CEF25EEA2C33E9D750FA3D@eigenstate.org> Message-ID: <10AAEA9F-8315-443F-80CB-150974BF054A@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: non-blocking extended hardware-aware method-oriented optimizer Subject: Re: [9front] user none: cwfs vs hjfs Reply-To: 9front@9front.org Precedence: bulk On January 21, 2021 7:24:05 PM EST, ori@eigenstate=2Eorg wrote: >Quoth Stanley Lieber : >> On January 21, 2021 6:26:27 PM EST, Silas McCroskey wrote: >> >> right now, running as user none is the only way to mask proc and ot= her # file system data=2E >> > >> >How so? >> > >> >RFNOMNT If set, subsequent mounts into the new name space >> > and dereferencing of pathnames starting with # are >> > disallowed=2E >> > >> >- sam-d >> > >>=20 >> let's stipulate i don't know what i'm talking about=2E >>=20 >> when i brought this up with cinap and ori on irc they agreed there is a= bit of a problem here=2E maybe we're all wrong, or maybe i misunderstood t= heir confirmation of my observations=2E >>=20 >> observed: hjfs handles user none differently=2E > >Yes=2E Let's normalize the behavior=2E Since it seems >like the cwfs behavior is expected and intended, >I'd want to patch hjfs to match it=2E > >I'm happy to give you (and anyone else following) >time to fix bugs, maybe going as far as putting >the change behind a console knob for a few weeks >for testing=2E I'd want the knob to go away quickly, >though=2E > >> observed: as a regular user i was able to access # after rfork m=2E > >That is unexpected -- rfork m works as documented for me, >though I think we punched a couple of holes to make it >more useful=2E Without '#|', rc would be entirely broken >after 'rfork m'=2E > > cpu% rfork m > cpu% for(d in `{awk '{print $1}' /dev/drivers}){ > ls $d>/dev/null && echo allowed: $d > } > ls: #/: mount/attach disallowed > allowed: #c > ls: #=C2=B6: mount/attach disallowed > ls: #P: mount/attach disallowed > ls: #$: mount/attach disallowed > allowed: #e > allowed: #| > allowed: #p > ls: #M: mount/attach disallowed > ls: #s: mount/attach disallowed > ls: #=CF=83: mount/attach disallowed > allowed: #d > ls: #r: mount/attach disallowed > ls: #D: mount/attach disallowed > ls: #a: mount/attach disallowed > ls: #=C2=A4: mount/attach disallowed > ls: #K: mount/attach disallowed > ls: #k: mount/attach disallowed > ls: #l: mount/attach disallowed > ls: #B: mount/attach disallowed > ls: #I: mount/attach disallowed > ls: #i: mount/attach disallowed > ls: #m: mount/attach disallowed > ls: #b: mount/attach disallowed > ls: #v: mount/attach disallowed > ls: #S: mount/attach disallowed > ls: #=C3=A6: mount/attach disallowed > ls: #A: mount/attach disallowed > ls: #t: mount/attach disallowed > ls: #u: mount/attach disallowed > ls: #g: mount/attach disallowed > ls: #X: mount/attach disallowed > ls: #=CE=94: mount/attach disallowed > >On the other hand: > > cpu% auth/none > cpu% for(d in `{awk '{print $1}' /dev/drivers}){ > ls $d>/dev/null && echo allowed: $d > } > allowed: #/ > allowed: #c > allowed: #=C2=B6 > allowed: #P > allowed: #$ > allowed: #e > allowed: #| > allowed: #p > ls: #M: mount/attach disallowed > allowed: #s > allowed: #=CF=83 > allowed: #d > allowed: #r > allowed: #D > allowed: #a > allowed: #=C2=A4 > allowed: #K > allowed: #k > allowed: #l > allowed: #B > allowed: #I > ls: #i: no frame buffer > allowed: #m > ls: #b: permission denied > allowed: #v > allowed: #S > allowed: #=C3=A6 > ls: #A: no free devices > allowed: #t > allowed: #u > allowed: #g > allowed: #X > allowed: #=CE=94 > > i run most of my services as regular users already (upas being the tricky = one who changes its user under the hood)=2E for this reason, /mail/queue al= ready has to be chmod 777=2E user mailboxes are also a problem if some serv= ice like imap is accessing them=2E if none can acces them, anyone can=2E et= c=2E, etc=2E, etc=2E hjfs: if no one else objects i'm ready for the breaking change any time, b= ut, yeah, a warning and a knob is probably good for a short period=2E rfork m: yes, it was the punched holes i observed=2E the man page sam-d qu= oted seems to disagree with the source=2E also, i did not notice this discr= epancy between rfork m and user none=2E my most troublesome use case has been 9bbs, which does stupid things anywa= y, but also unexpectedly exposed stuff under # no matter if running as user= none (where anyone on the fs can read all its passwords) or as a regular u= ser (where nobody else on the 9fs can read all its passwords)=2E people reflexively blame observations such as these on writing rc instead = of c, but i tend to ignore sic bigotry in light of the fact we've got more = fundamental fish to fry! wheeeeeeeee sl