Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber <sl@stanleylieber.com>]

On January 21, 2021 7:24:05 PM EST, ori@eigenstate.org wrote:
>Quoth Stanley Lieber <sl@stanleylieber.com>:
>> On January 21, 2021 6:26:27 PM EST, Silas McCroskey <inkswinc@gmail.com> wrote:
>> >>  right now, running as user none is the only way to mask proc and other # file system data.
>> >
>> >How so?
>> >
>> >RFNOMNT   If set, subsequent mounts into the new name space
>> >                    and dereferencing of pathnames starting with # are
>> >                    disallowed.
>> >
>> >- sam-d
>> >
>> 
>> let's stipulate i don't know what i'm talking about.
>> 
>> when i brought this up with cinap and ori on irc they agreed there is a bit of a problem here. maybe we're all wrong, or maybe i misunderstood their confirmation of my observations.
>> 
>> observed: hjfs handles user none differently.
>
>Yes. Let's normalize the behavior. Since it seems
>like the cwfs behavior is expected and intended,
>I'd want to patch hjfs to match it.
>
>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. I'd want the knob to go away quickly,
>though.
>
>> observed: as a regular user i was able to access # after rfork m.
>
>That is unexpected -- rfork m works as documented for me,
>though I think we punched a couple of holes to make it
>more useful. Without '#|', rc would be entirely broken
>after 'rfork m'.
>
>	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: #¶: 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: #σ: mount/attach disallowed
>	allowed: #d
>	ls: #r: mount/attach disallowed
>	ls: #D: mount/attach disallowed
>	ls: #a: mount/attach disallowed
>	ls: #¤: 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: #æ: 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: #Δ: 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: #¶
>	allowed: #P
>	allowed: #$
>	allowed: #e
>	allowed: #|
>	allowed: #p
>	ls: #M: mount/attach disallowed
>	allowed: #s
>	allowed: #σ
>	allowed: #d
>	allowed: #r
>	allowed: #D
>	allowed: #a
>	allowed: #¤
>	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: #æ
>	ls: #A: no free devices
>	allowed: #t
>	allowed: #u
>	allowed: #g
>	allowed: #X
>	allowed: #Δ
>
>

i run most of my services as regular users already (upas being the tricky one who changes its user under the hood). for this reason, /mail/queue already has to be chmod 777. user mailboxes are also a problem if some service like imap is accessing them. if none can acces them, anyone can. etc., etc., etc.

hjfs: if no one else objects i'm ready for the breaking change any time, but, yeah, a warning and a knob is probably good for a short period.

rfork m: yes, it was the punched holes i observed. the man page sam-d quoted seems to disagree with the source. also, i did not notice this discrepancy between rfork m and user none.

my most troublesome use case has been 9bbs, which does stupid things anyway, 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 user (where nobody else on the 9fs can read all its passwords).

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