* [9front] user none: cwfs vs hjfs @ 2021-01-19 20:16 Stanley Lieber 2021-01-19 20:36 ` hiro 2021-01-19 20:51 ` Silas McCroskey 0 siblings, 2 replies; 35+ messages in thread From: Stanley Lieber @ 2021-01-19 20:16 UTC (permalink / raw) To: 9front can someone with a working cwfs install please verify that user none is unable to access files (even user none g+rw) unless they are world readable? hjfs allows user none to access files that are not world readable. thanks, sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 20:16 [9front] user none: cwfs vs hjfs Stanley Lieber @ 2021-01-19 20:36 ` hiro 2021-01-19 20:51 ` Silas McCroskey 1 sibling, 0 replies; 35+ messages in thread From: hiro @ 2021-01-19 20:36 UTC (permalink / raw) To: 9front cpu% date > blabla; ls -l blabla; auth/none cat blabla --rw-r--r-- M 3288 hiro hiro 29 Jan 19 21:34 blabla Tue Jan 19 21:34:07 CET 2021 cwfs manpage has: The group numbered 9999, normally called noworld, is special on the file server. Any user belonging to that group has attenuated access privileges. Specifically, when checking such a user's access to files, the file's permission bits are first ANDed with 0770 for normal files or 0771 for directories. The effect is to deny world access permissions to noworld users, except when walking directories. but i don't know how to check if none is part of noworld group...? On 1/19/21, Stanley Lieber <sl@stanleylieber.com> wrote: > can someone with a working cwfs install please verify that user none is > unable to access files (even user none g+rw) unless they are world > readable? > > hjfs allows user none to access files that are not world readable. > > thanks, > > sl > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 20:16 [9front] user none: cwfs vs hjfs Stanley Lieber 2021-01-19 20:36 ` hiro @ 2021-01-19 20:51 ` Silas McCroskey 2021-01-19 20:57 ` Silas McCroskey 2021-01-19 21:07 ` Stanley Lieber 1 sibling, 2 replies; 35+ messages in thread From: Silas McCroskey @ 2021-01-19 20:51 UTC (permalink / raw) To: 9front mystia% auth/none cat /usr/glenda/secstore cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access permission denied mystia% auth/none ls -l /usr/glenda/priv/ ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied mystia% anything more specific to try out? - sam-d ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 20:51 ` Silas McCroskey @ 2021-01-19 20:57 ` Silas McCroskey 2021-01-19 21:35 ` Stanley Lieber 2021-01-19 21:07 ` Stanley Lieber 1 sibling, 1 reply; 35+ messages in thread From: Silas McCroskey @ 2021-01-19 20:57 UTC (permalink / raw) To: 9front ah, missed the "owned by user none g+rw" part. Same behavior: mystia% ls -ld /usr/none/incoming d-rwxrwx--- M 5300 none ftp 0 Nov 15 2016 /usr/none/incoming mystia% auth/none ls -l /usr/none/incoming ls: /usr/none/incoming: '/usr/none/incoming' access permission denied mystia% auth/none chmod 0777 /usr/none/incoming mystia% auth/none touch /usr/none/incoming/file mystia% auth/none chmod 0770 /usr/none/incoming/file mystia% auth/none cat /usr/none/incoming/file cat: can't open /usr/none/incoming/file: '/usr/none/incoming/file' access permission denied mystia% - sam-d On Tue, Jan 19, 2021 at 12:51 PM Silas McCroskey <inkswinc@gmail.com> wrote: > > mystia% auth/none cat /usr/glenda/secstore > cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access > permission denied > mystia% auth/none ls -l /usr/glenda/priv/ > ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied > mystia% > > anything more specific to try out? > > - sam-d ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 20:57 ` Silas McCroskey @ 2021-01-19 21:35 ` Stanley Lieber 2021-01-19 21:54 ` hiro 0 siblings, 1 reply; 35+ messages in thread From: Stanley Lieber @ 2021-01-19 21:35 UTC (permalink / raw) To: 9front On January 19, 2021 3:57:29 PM EST, Silas McCroskey <inkswinc@gmail.com> wrote: >ah, missed the "owned by user none g+rw" part. > >Same behavior: > >mystia% ls -ld /usr/none/incoming >d-rwxrwx--- M 5300 none ftp 0 Nov 15 2016 /usr/none/incoming >mystia% auth/none ls -l /usr/none/incoming >ls: /usr/none/incoming: '/usr/none/incoming' access permission denied >mystia% auth/none chmod 0777 /usr/none/incoming >mystia% auth/none touch /usr/none/incoming/file >mystia% auth/none chmod 0770 /usr/none/incoming/file >mystia% auth/none cat /usr/none/incoming/file >cat: can't open /usr/none/incoming/file: '/usr/none/incoming/file' >access permission denied >mystia% > >- sam-d > >On Tue, Jan 19, 2021 at 12:51 PM Silas McCroskey <inkswinc@gmail.com> wrote: >> >> mystia% auth/none cat /usr/glenda/secstore >> cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access >> permission denied >> mystia% auth/none ls -l /usr/glenda/priv/ >> ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied >> mystia% >> >> anything more specific to try out? >> >> - sam-d > i first noticed this discrepancy back when i was first screwing around with /mail/queue; i mentioned it, but nobody was interested. hjfs just honors normal file permissions. at the very least, shouldn't all our file systems treat user none the same way? sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 21:35 ` Stanley Lieber @ 2021-01-19 21:54 ` hiro 2021-01-19 21:58 ` Anthony Martin 2021-01-19 23:04 ` Silas McCroskey 0 siblings, 2 replies; 35+ messages in thread From: hiro @ 2021-01-19 21:54 UTC (permalink / raw) To: 9front i was under the impression that cwfs, like hjfs, wrongly allows access. do notice that the cat in my example succeeds and prints date. it shouldn't IMO. On 1/19/21, Stanley Lieber <sl@stanleylieber.com> wrote: > On January 19, 2021 3:57:29 PM EST, Silas McCroskey <inkswinc@gmail.com> > wrote: >>ah, missed the "owned by user none g+rw" part. >> >>Same behavior: >> >>mystia% ls -ld /usr/none/incoming >>d-rwxrwx--- M 5300 none ftp 0 Nov 15 2016 /usr/none/incoming >>mystia% auth/none ls -l /usr/none/incoming >>ls: /usr/none/incoming: '/usr/none/incoming' access permission denied >>mystia% auth/none chmod 0777 /usr/none/incoming >>mystia% auth/none touch /usr/none/incoming/file >>mystia% auth/none chmod 0770 /usr/none/incoming/file >>mystia% auth/none cat /usr/none/incoming/file >>cat: can't open /usr/none/incoming/file: '/usr/none/incoming/file' >>access permission denied >>mystia% >> >>- sam-d >> >>On Tue, Jan 19, 2021 at 12:51 PM Silas McCroskey <inkswinc@gmail.com> >> wrote: >>> >>> mystia% auth/none cat /usr/glenda/secstore >>> cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access >>> permission denied >>> mystia% auth/none ls -l /usr/glenda/priv/ >>> ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied >>> mystia% >>> >>> anything more specific to try out? >>> >>> - sam-d >> > > i first noticed this discrepancy back when i was first screwing around with > /mail/queue; i mentioned it, but nobody was interested. hjfs just honors > normal file permissions. at the very least, shouldn't all our file systems > treat user none the same way? > > sl > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 21:54 ` hiro @ 2021-01-19 21:58 ` Anthony Martin 2021-01-21 16:22 ` ori 2021-01-19 23:04 ` Silas McCroskey 1 sibling, 1 reply; 35+ messages in thread From: Anthony Martin @ 2021-01-19 21:58 UTC (permalink / raw) To: 9front /sys/src/cmd/cwfs/sub.c:/^iaccess /sys/src/cmd/hjfs/auth.c:/^permcheck /sys/src/cmd/fossil/9p.c:/^permFile Hjfs is the odd man out. Cheers, Anthony ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 21:58 ` Anthony Martin @ 2021-01-21 16:22 ` ori 2021-01-21 17:05 ` sirjofri 0 siblings, 1 reply; 35+ messages in thread From: ori @ 2021-01-21 16:22 UTC (permalink / raw) To: 9front Quoth Anthony Martin <ality@pbrane.org>: > /sys/src/cmd/cwfs/sub.c:/^iaccess > /sys/src/cmd/hjfs/auth.c:/^permcheck > /sys/src/cmd/fossil/9p.c:/^permFile > > Hjfs is the odd man out. > > Cheers, > Anthony Unfortunately I can't test, since I don't currently have hjfs -- but I think this change brings hjfs in sync. diff -r 01125acb5565 sys/src/cmd/hjfs/auth.c --- a/sys/src/cmd/hjfs/auth.c Tue Jan 19 19:56:38 2021 -0800 +++ b/sys/src/cmd/hjfs/auth.c Thu Jan 21 08:21:34 2021 -0800 @@ -301,10 +301,13 @@ if((fs->flags & FSNOPERM) != 0) return 1; perm = d->mode & 0777; - if(d->uid == uid) - perm >>= 6; - else if(ingroup(fs, uid, d->gid, 0)) - perm >>= 3; + /* uid none gets only other permissions */ + if(d->uid != 0) { + if(d->uid == uid) + perm >>= 6; + else if(ingroup(fs, uid, d->gid, 0)) + perm >>= 3; + } switch(mode & 3){ case OREAD: return (perm & 4) != 0; ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 16:22 ` ori @ 2021-01-21 17:05 ` sirjofri 2021-01-21 17:36 ` Stanley Lieber 0 siblings, 1 reply; 35+ messages in thread From: sirjofri @ 2021-01-21 17:05 UTC (permalink / raw) To: 9front Hello, just a sidenote, the paper about 9 (/sys/doc/9.ps) also mentions the behavior of none, it basically always has world permissions, independent of the ownership, iirc. sirjofri ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 17:05 ` sirjofri @ 2021-01-21 17:36 ` Stanley Lieber 2021-01-21 22:01 ` hiro 0 siblings, 1 reply; 35+ messages in thread From: Stanley Lieber @ 2021-01-21 17:36 UTC (permalink / raw) To: 9front On January 21, 2021 12:05:58 PM EST, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote: >Hello, > >just a sidenote, the paper about 9 (/sys/doc/9.ps) also mentions the >behavior of none, it basically always has world permissions, independent >of the ownership, iirc. > >sirjofri > yes, the whole problem here is hjfs does something different. i've been on hjfs so long i became accustomed to its behavior and expected it everywhere. fixing hjfs may break assumptions in some people's setups. sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 17:36 ` Stanley Lieber @ 2021-01-21 22:01 ` hiro 2021-01-21 22:15 ` Stanley Lieber 0 siblings, 1 reply; 35+ messages in thread From: hiro @ 2021-01-21 22:01 UTC (permalink / raw) To: 9front otoh not fixing hjfs may break security assumptions. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 22:01 ` hiro @ 2021-01-21 22:15 ` Stanley Lieber 2021-01-21 22:51 ` hiro 0 siblings, 1 reply; 35+ messages in thread From: Stanley Lieber @ 2021-01-21 22:15 UTC (permalink / raw) To: 9front On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote: >otoh not fixing hjfs may break security assumptions. > yes. i think we should fix hjfs. a lot of stuff relies on user none doing what it does in cwfs. the most import thing is that all file systems behave the same way. 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. i think they got lazy with user none. we need some finer grade control over user capabilities. sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 22:15 ` Stanley Lieber @ 2021-01-21 22:51 ` hiro 2021-01-21 22:55 ` hiro 2021-01-21 23:00 ` Stanley Lieber 0 siblings, 2 replies; 35+ messages in thread From: hiro @ 2021-01-21 22:51 UTC (permalink / raw) To: 9front why do you think running every service as none is a recommended practice? On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote: > On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote: >>otoh not fixing hjfs may break security assumptions. >> > > yes. i think we should fix hjfs. a lot of stuff relies on user none doing > what it does in cwfs. the most import thing is that all file systems behave > the same way. > > 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. > > i think they got lazy with user none. we need some finer grade control over > user capabilities. > > sl > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 22:51 ` hiro @ 2021-01-21 22:55 ` hiro 2021-01-21 23:26 ` Silas McCroskey 2021-01-21 23:44 ` Stanley Lieber 2021-01-21 23:00 ` Stanley Lieber 1 sibling, 2 replies; 35+ messages in thread From: hiro @ 2021-01-21 22:55 UTC (permalink / raw) To: 9front 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. 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. On 1/21/21, hiro <23hiro@gmail.com> wrote: > why do you think running every service as none is a recommended practice? > > On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote: >> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote: >>>otoh not fixing hjfs may break security assumptions. >>> >> >> yes. i think we should fix hjfs. a lot of stuff relies on user none doing >> what it does in cwfs. the most import thing is that all file systems >> behave >> the same way. >> >> 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. >> >> i think they got lazy with user none. we need some finer grade control >> over >> user capabilities. >> >> sl >> > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 22:55 ` hiro @ 2021-01-21 23:26 ` Silas McCroskey 2021-01-21 23:55 ` Stanley Lieber 2021-01-22 0:10 ` Anthony Martin 2021-01-21 23:44 ` Stanley Lieber 1 sibling, 2 replies; 35+ messages in thread From: Silas McCroskey @ 2021-01-21 23:26 UTC (permalink / raw) To: 9front > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 23:26 ` Silas McCroskey @ 2021-01-21 23:55 ` Stanley Lieber 2021-01-22 0:13 ` Silas McCroskey 2021-01-22 0:24 ` ori 2021-01-22 0:10 ` Anthony Martin 1 sibling, 2 replies; 35+ messages in thread From: Stanley Lieber @ 2021-01-21 23:55 UTC (permalink / raw) To: 9front 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. observed: as a regular user i was able to access # after rfork m. i'll bow out pending this getting swept under the rug again. sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 23:55 ` Stanley Lieber @ 2021-01-22 0:13 ` Silas McCroskey 2021-01-23 15:08 ` cinap_lenrek 2021-01-22 0:24 ` ori 1 sibling, 1 reply; 35+ messages in thread From: Silas McCroskey @ 2021-01-22 0:13 UTC (permalink / raw) To: 9front Huh, I can confirm RFNOMNT seems to not quite work as implied. "rfork m; ls `{awk '{print $1}' /dev/drivers}" Showed a lot of "mount/attach disallowed", but some were still allowed (including #p). - sam-d ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-22 0:13 ` Silas McCroskey @ 2021-01-23 15:08 ` cinap_lenrek 0 siblings, 0 replies; 35+ messages in thread From: cinap_lenrek @ 2021-01-23 15:08 UTC (permalink / raw) To: 9front we'r working towards getting rid of these exceptions... tho #| will always be required as binding is how you make a anonymous pipe. -- cinap ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 23:55 ` Stanley Lieber 2021-01-22 0:13 ` Silas McCroskey @ 2021-01-22 0:24 ` ori 2021-01-22 0:53 ` Stanley Lieber 1 sibling, 1 reply; 35+ messages in thread From: ori @ 2021-01-22 0:24 UTC (permalink / raw) To: 9front 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: #Δ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-22 0:24 ` ori @ 2021-01-22 0:53 ` Stanley Lieber 2021-01-22 9:53 ` hiro 0 siblings, 1 reply; 35+ messages in thread From: Stanley Lieber @ 2021-01-22 0:53 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-22 0:53 ` Stanley Lieber @ 2021-01-22 9:53 ` hiro 0 siblings, 0 replies; 35+ messages in thread From: hiro @ 2021-01-22 9:53 UTC (permalink / raw) To: 9front > /mail/queue already has to be chmod 777 yeah that's definitely fucked up. did they have another way to separate /mail/queue from the users ?! that sounds just wrong, regardless of how we change none or `rfork m` behaviors. > the man page sam-d quoted seems to disagree with the source. yeah, that's bad. > 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! remember, even rcpu is based on rc :D ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 23:26 ` Silas McCroskey 2021-01-21 23:55 ` Stanley Lieber @ 2021-01-22 0:10 ` Anthony Martin 1 sibling, 0 replies; 35+ messages in thread From: Anthony Martin @ 2021-01-22 0:10 UTC (permalink / raw) To: 9front Silas McCroskey <inkswinc@gmail.com> once said: > RFNOMNT If set, subsequent mounts into the new name space > and dereferencing of pathnames starting with # are > disallowed. /sys/src/9/port/chan.c:1321,1335 Cheers, Anthony ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 22:55 ` hiro 2021-01-21 23:26 ` Silas McCroskey @ 2021-01-21 23:44 ` Stanley Lieber 2021-01-22 0:00 ` Silas McCroskey ` (2 more replies) 1 sibling, 3 replies; 35+ messages in thread From: Stanley Lieber @ 2021-01-21 23:44 UTC (permalink / raw) To: 9front On January 21, 2021 5:55:00 PM EST, hiro <23hiro@gmail.com> 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. > >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. > >On 1/21/21, hiro <23hiro@gmail.com> wrote: >> why do you think running every service as none is a recommended practice? >> >> On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote: >>> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote: >>>>otoh not fixing hjfs may break security assumptions. >>>> >>> >>> yes. i think we should fix hjfs. a lot of stuff relies on user none doing >>> what it does in cwfs. the most import thing is that all file systems >>> behave >>> the same way. >>> >>> 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. >>> >>> i think they got lazy with user none. we need some finer grade control >>> over >>> user capabilities. >>> >>> 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. this means any user on the file system can also access those files unless special steps are taken to prevent it. for example, upas becomes user none to process files through /mail/queue no matter who upas starts out running as. the default listener runs as none and scans the service directory. any user on the file system (including none) must be trusted with any file none can access. there's a basic conflict here that has no current solution except "run everything that requires file privacy on separate file systems." regular users honor finer grained file permissions, but cannot be masked from the special # file system. there is a basic conflict here that has no solution at all. any regular user must be trusted with proc, binding, unbinding, this is why user none exists in the first place. the disconnect here is between file and process permissions. they are completely different things. we have fine grained file permissions but auth is all or nothing. sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 23:44 ` Stanley Lieber @ 2021-01-22 0:00 ` Silas McCroskey 2021-01-22 9:14 ` hiro 2021-01-22 9:41 ` hiro 2 siblings, 0 replies; 35+ messages in thread From: Silas McCroskey @ 2021-01-22 0:00 UTC (permalink / raw) To: 9front > regular users honor finer grained file permissions, but cannot be masked from the special # file system. there is a basic conflict here that has no solution at all. any regular user must be trusted with proc, binding, unbinding, this is why user none exists in the first place. Again, I think RFNOMNT makes this false, at least if it actually works as advertised (I've never had reason to test it). The only justification I can come up with for user none is anonymous read access to the filesystem over the network (when that's enabled). It does seem like I'm missing something, because I don't see why services would've been written to become none in that case. - Silas ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 23:44 ` Stanley Lieber 2021-01-22 0:00 ` Silas McCroskey @ 2021-01-22 9:14 ` hiro 2021-01-22 14:51 ` Stanley Lieber 2021-01-22 9:41 ` hiro 2 siblings, 1 reply; 35+ messages in thread From: hiro @ 2021-01-22 9:14 UTC (permalink / raw) To: 9front > 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. i am not saying it is the best solution, just trying to stay on the track that the bell-labs people have laid out. i am not saying we didn't break it. but if we know the intent of the basic architecture we might be able to fix it without creating a second system. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-22 9:14 ` hiro @ 2021-01-22 14:51 ` Stanley Lieber 2021-01-22 15:01 ` hiro 0 siblings, 1 reply; 35+ messages in thread From: Stanley Lieber @ 2021-01-22 14:51 UTC (permalink / raw) To: 9front On January 22, 2021 4:14:24 AM EST, hiro <23hiro@gmail.com> 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. > >i am not saying it is the best solution, just trying to stay on the >track that the bell-labs people have laid out. > >i am not saying we didn't break it. but if we know the intent of the >basic architecture we might be able to fix it without creating a >second system. > yeah, i'm with you there. i really think they just tried to sidestep this whole issue by stipulating anyone with fs access was trusted. remember the "joke" about securing the fs by locking the server room door? sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-22 14:51 ` Stanley Lieber @ 2021-01-22 15:01 ` hiro 2021-01-22 15:39 ` Stanley Lieber 0 siblings, 1 reply; 35+ messages in thread From: hiro @ 2021-01-22 15:01 UTC (permalink / raw) To: 9front well there's a lot of truth in that joke. and it really does look like they thought about proper security concepts. but providing a nice basis, an OS, and making sure every program uses it correctly are two different things. it might be that this dissonance can be explained some other way. for example if the people involved in making the email stuff were different folks, who didn't know how to fit into that security architecture. as email has proven to be a longer-term thing after all, perhaps it's worth fixing the broken upas assumptions so that upas fits again with the rest of this system. On 1/22/21, Stanley Lieber <sl@stanleylieber.com> wrote: > On January 22, 2021 4:14:24 AM EST, hiro <23hiro@gmail.com> 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. >> >>i am not saying it is the best solution, just trying to stay on the >>track that the bell-labs people have laid out. >> >>i am not saying we didn't break it. but if we know the intent of the >>basic architecture we might be able to fix it without creating a >>second system. >> > > yeah, i'm with you there. i really think they just tried to sidestep this > whole issue by stipulating anyone with fs access was trusted. remember the > "joke" about securing the fs by locking the server room door? > > sl > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-22 15:01 ` hiro @ 2021-01-22 15:39 ` Stanley Lieber 0 siblings, 0 replies; 35+ messages in thread From: Stanley Lieber @ 2021-01-22 15:39 UTC (permalink / raw) To: 9front On January 22, 2021 10:01:34 AM EST, hiro <23hiro@gmail.com> wrote: >well there's a lot of truth in that joke. > >and it really does look like they thought about proper security >concepts. but providing a nice basis, an OS, and making sure every >program uses it correctly are two different things. > >it might be that this dissonance can be explained some other way. for >example if the people involved in making the email stuff were >different folks, who didn't know how to fit into that security >architecture. > >as email has proven to be a longer-term thing after all, perhaps it's >worth fixing the broken upas assumptions so that upas fits again with >the rest of this system. > >On 1/22/21, Stanley Lieber <sl@stanleylieber.com> wrote: >> On January 22, 2021 4:14:24 AM EST, hiro <23hiro@gmail.com> 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. >>> >>>i am not saying it is the best solution, just trying to stay on the >>>track that the bell-labs people have laid out. >>> >>>i am not saying we didn't break it. but if we know the intent of the >>>basic architecture we might be able to fix it without creating a >>>second system. >>> >> >> yeah, i'm with you there. i really think they just tried to sidestep this >> whole issue by stipulating anyone with fs access was trusted. remember the >> "joke" about securing the fs by locking the server room door? >> >> sl >> > there is definitely a disconnect between "everyone uses the same fs" and the way they implemented all these services for mere users. sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 23:44 ` Stanley Lieber 2021-01-22 0:00 ` Silas McCroskey 2021-01-22 9:14 ` hiro @ 2021-01-22 9:41 ` hiro 2 siblings, 0 replies; 35+ messages in thread From: hiro @ 2021-01-22 9:41 UTC (permalink / raw) To: 9front > upas becomes user none to process files through /mail/queue no > matter who upas starts out running as. sounds like a bug > that has no current solution except "run everything that requires file > privacy on separate file systems." later on you say file permissions are granular enough. so i don't know why you say here that "file privacy" would be a problem. > but cannot be masked > from the special # file system. oh? i was not aware. do you have a trivial example for this, i'm curious! > solution at all. any regular user must be trusted with proc, binding, > unbinding, this is why user none exists in the first place. > the disconnect here is between file and process permissions. they are > completely different things. we have fine grained file permissions but auth > is all or nothing. so is there a problem with /proc ? can we read other user's memory or something? or what did you find? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 22:51 ` hiro 2021-01-21 22:55 ` hiro @ 2021-01-21 23:00 ` Stanley Lieber 2021-01-21 23:08 ` Stanley Lieber 1 sibling, 1 reply; 35+ messages in thread From: Stanley Lieber @ 2021-01-21 23:00 UTC (permalink / raw) To: 9front On January 21, 2021 5:51:02 PM EST, hiro <23hiro@gmail.com> wrote: >why do you think running every service as none is a recommended practice? > >On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote: >> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote: >>>otoh not fixing hjfs may break security assumptions. >>> >> >> yes. i think we should fix hjfs. a lot of stuff relies on user none doing >> what it does in cwfs. the most import thing is that all file systems behave >> the same way. >> >> 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. >> >> i think they got lazy with user none. we need some finer grade control over >> user capabilities. >> >> sl >> > upas for one hardcodes switching to user none even if you don't run it as user none. sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-21 23:00 ` Stanley Lieber @ 2021-01-21 23:08 ` Stanley Lieber 0 siblings, 0 replies; 35+ messages in thread From: Stanley Lieber @ 2021-01-21 23:08 UTC (permalink / raw) To: 9front On January 21, 2021 6:00:33 PM EST, Stanley Lieber <sl@stanleylieber.com> wrote: >On January 21, 2021 5:51:02 PM EST, hiro <23hiro@gmail.com> wrote: >>why do you think running every service as none is a recommended practice? >> >>On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote: >>> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote: >>>>otoh not fixing hjfs may break security assumptions. >>>> >>> >>> yes. i think we should fix hjfs. a lot of stuff relies on user none doing >>> what it does in cwfs. the most import thing is that all file systems behave >>> the same way. >>> >>> 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. >>> >>> i think they got lazy with user none. we need some finer grade control over >>> user capabilities. >>> >>> sl >>> >> > >upas for one hardcodes switching to user none even if you don't run it as user none. > >sl > right now, running as user none is the only way to mask proc and other # file system data. it's the default user for the listener, hiro. sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 21:54 ` hiro 2021-01-19 21:58 ` Anthony Martin @ 2021-01-19 23:04 ` Silas McCroskey 2021-01-20 1:12 ` hiro 1 sibling, 1 reply; 35+ messages in thread From: Silas McCroskey @ 2021-01-19 23:04 UTC (permalink / raw) To: 9front On Tue, Jan 19, 2021 at 2:05 PM hiro <23hiro@gmail.com> wrote: > > i was under the impression that cwfs, like hjfs, wrongly allows > access. do notice that the cat in my example succeeds and prints date. > it shouldn't IMO. That behavior is correct. None has read access because the file is world-readable. There's nothing wrong in your example. - sam-d ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 23:04 ` Silas McCroskey @ 2021-01-20 1:12 ` hiro 2021-01-20 1:50 ` Stanley Lieber 0 siblings, 1 reply; 35+ messages in thread From: hiro @ 2021-01-20 1:12 UTC (permalink / raw) To: 9front i can't even do chgrp none file, -- not in group On 1/20/21, Silas McCroskey <inkswinc@gmail.com> wrote: > On Tue, Jan 19, 2021 at 2:05 PM hiro <23hiro@gmail.com> wrote: >> >> i was under the impression that cwfs, like hjfs, wrongly allows >> access. do notice that the cat in my example succeeds and prints date. >> it shouldn't IMO. > > That behavior is correct. None has read access because the file is > world-readable. There's nothing wrong in your example. > > - sam-d > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-20 1:12 ` hiro @ 2021-01-20 1:50 ` Stanley Lieber 0 siblings, 0 replies; 35+ messages in thread From: Stanley Lieber @ 2021-01-20 1:50 UTC (permalink / raw) To: 9front On January 19, 2021 8:12:46 PM EST, hiro <23hiro@gmail.com> wrote: >i can't even do chgrp none file, -- not in group > >On 1/20/21, Silas McCroskey <inkswinc@gmail.com> wrote: >> On Tue, Jan 19, 2021 at 2:05 PM hiro <23hiro@gmail.com> wrote: >>> >>> i was under the impression that cwfs, like hjfs, wrongly allows >>> access. do notice that the cat in my example succeeds and prints date. >>> it shouldn't IMO. >> >> That behavior is correct. None has read access because the file is >> world-readable. There's nothing wrong in your example. >> >> - sam-d >> > yes, file permissions will apply as normal so long as you're not actually user none. the problem i'm describing here is cwfs and hjfs behave differently for user none. sl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [9front] user none: cwfs vs hjfs 2021-01-19 20:51 ` Silas McCroskey 2021-01-19 20:57 ` Silas McCroskey @ 2021-01-19 21:07 ` Stanley Lieber 1 sibling, 0 replies; 35+ messages in thread From: Stanley Lieber @ 2021-01-19 21:07 UTC (permalink / raw) To: 9front On January 19, 2021 3:51:37 PM EST, Silas McCroskey <inkswinc@gmail.com> wrote: >mystia% auth/none cat /usr/glenda/secstore >cat: can't open /usr/glenda/secstore: '/usr/glenda/secstore' access >permission denied >mystia% auth/none ls -l /usr/glenda/priv/ >ls: /usr/glenda/priv/: '/usr/glenda/priv/' access permission denied >mystia% > >anything more specific to try out? > >- sam-d > ; chmod 700 file. # file not owned by none ; chgrp none file && chmod g+wr file ; auth/none cat file sl ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2021-01-23 15:35 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-19 20:16 [9front] user none: cwfs vs hjfs Stanley Lieber 2021-01-19 20:36 ` hiro 2021-01-19 20:51 ` Silas McCroskey 2021-01-19 20:57 ` Silas McCroskey 2021-01-19 21:35 ` Stanley Lieber 2021-01-19 21:54 ` hiro 2021-01-19 21:58 ` Anthony Martin 2021-01-21 16:22 ` ori 2021-01-21 17:05 ` sirjofri 2021-01-21 17:36 ` Stanley Lieber 2021-01-21 22:01 ` hiro 2021-01-21 22:15 ` Stanley Lieber 2021-01-21 22:51 ` hiro 2021-01-21 22:55 ` hiro 2021-01-21 23:26 ` Silas McCroskey 2021-01-21 23:55 ` Stanley Lieber 2021-01-22 0:13 ` Silas McCroskey 2021-01-23 15:08 ` cinap_lenrek 2021-01-22 0:24 ` ori 2021-01-22 0:53 ` Stanley Lieber 2021-01-22 9:53 ` hiro 2021-01-22 0:10 ` Anthony Martin 2021-01-21 23:44 ` Stanley Lieber 2021-01-22 0:00 ` Silas McCroskey 2021-01-22 9:14 ` hiro 2021-01-22 14:51 ` Stanley Lieber 2021-01-22 15:01 ` hiro 2021-01-22 15:39 ` Stanley Lieber 2021-01-22 9:41 ` hiro 2021-01-21 23:00 ` Stanley Lieber 2021-01-21 23:08 ` Stanley Lieber 2021-01-19 23:04 ` Silas McCroskey 2021-01-20 1:12 ` hiro 2021-01-20 1:50 ` Stanley Lieber 2021-01-19 21:07 ` Stanley Lieber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).