[9front] notes on user none

[9front] notes on user none

[Anthony Martin]

I remembered investigating the restrictions on user none
in the past so I went and dug out my notes. They're only
applicable to fossil and cwfs, though, so someone else
will have to go through the hjfs code to compare.

The notes are attached below.

Cheers,
  Anthony

# from /sys/doc/9.ms
Finally, a special user called none has no password and is always
allowed to connect; anyone may claim to be none. None has restricted
permissions; for example, it is not allowed to examine dump files and
can read only world-readable files.

# from /sys/doc/auth.ms
Factotum is the only process that needs to create capabilities, so all
the network servers can run as untrusted users (e.g., Plan 9's none or
Unix's nobody), which greatly reduces the harm done if a server is
buggy and is compromised.


# kernel
- documented
	- anyone can become none with none(8)
- undocumented
	- eve can change the owner of proc(3) files to none
	- none cannot use proc(3) to view or modify the state of other processes
	- none cannot create shr(3) files on 9front

# cwfs(4) and fossil(4)
- documented
	- none cannot authenticate a connection
		- auth(5) with uname "none" returns Rerror
	- none can be chaperoned on authenticated connections
		- attach(5) with afid NOFID sets uname to "none"
	- none has minimal access permissions (i.e. "world" or "other")
	- users in the "noworld" group are denied world access permissions
- undocumented
	- none cannot be a group leader
		- wstat(5) is limited

# fossil(4)
- documented
	- none cannot attach to an unauthenticated connection
		- unless the -N flag is given to listen or srv
	- users not in the "write" group cannot modify the file system
		- unless the group doesn't exist
- undocumented
	- none cannot modify file status information
		- wstat(5) returns Rerror

# cwfs(4)
- documented
	- none *can* attach to an unauthenticated connection
		- unless the nonone flag is set on 9front (undocumented)
- undocumented
	- none cannot attach to the dump file system
		- attach(5) returns Rerror

Re: [9front] notes on user none

[sirjofri]

Hello,

imo this is valuable research that should be documented if possible.

This also makes clear the none differences between fossil and cwfs, and 
it's a nice template to look how hjfs works. Sadly I have no hjfs running 
anywhere, only cwfs[1].

This also conforms to sl's suggestion to add nonone to cpurc or 
something, so that cwfs works more like fossil, which also makes the 
system more secure. I'd personally even think about making it the default 
and allow users to explicitly enable none authentication, but I don't 
think my vote counts that much. I'm sure ori, sl, cinap as well as many 
others have more experience to decide this.

just my 2 cents.

sirjofri

[1] the "experimental" note always tells me not to use it. Also I'm happy 
with cwfs and have no reason to switch to hjfs, although users report 
that hjfs is pretty stable.

Re: [9front] notes on user none

[hiro]

yeah, if making nonone the default makes it all more consistent with
how it was in the labs that's what we should do, i agree.

very nice writeup, anthony.

On 1/23/21, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
> Hello,
>
> imo this is valuable research that should be documented if possible.
>
> This also makes clear the none differences between fossil and cwfs, and
> it's a nice template to look how hjfs works. Sadly I have no hjfs running
> anywhere, only cwfs[1].
>
> This also conforms to sl's suggestion to add nonone to cpurc or
> something, so that cwfs works more like fossil, which also makes the
> system more secure. I'd personally even think about making it the default
> and allow users to explicitly enable none authentication, but I don't
> think my vote counts that much. I'm sure ori, sl, cinap as well as many
> others have more experience to decide this.
>
> just my 2 cents.
>
> sirjofri
>
> [1] the "experimental" note always tells me not to use it. Also I'm happy
> with cwfs and have no reason to switch to hjfs, although users report
> that hjfs is pretty stable.
>

Re: [9front] notes on user none

[cinap_lenrek]

# kernel
	- eve can change the owner of proc(3) files to none

note, this has been chnaged recently so that anyone;
not just eve; can become none thru chmod on its own
/proc/$pid/ctl file. this makes sense as that was
possible before by writing "none" into #c/user.

the idea is to deprecate #c/user at some point
in the future, removing any of the process context
sensitive files from it.

otherwise, thanks for the nice summay!

--
cinap

Re: [9front] notes on user none

[ori]

Quoth Anthony Martin <ality@pbrane.org>:
> I remembered investigating the restrictions on user none
> in the past so I went and dug out my notes. They're only
> applicable to fossil and cwfs, though, so someone else
> will have to go through the hjfs code to compare.

Thanks for the writeup, this is excellent.

One thing that's worth noting: The reason that none
only looks at world permissions is that *anyone* can
become none with no authentication -- which means
that a file readable by none is equivalent to a world
readable file.

Making 'none' only look at the world permissions is
a reasonable way to avoid fooling yourself.

Re: [9front] notes on user none

[magma698hfsp273p9f]

ori@eigenstate.org writes:

> One thing that's worth noting: The reason that none
> only looks at world permissions is that *anyone* can
> become none with no authentication -- which means
> that a file readable by none is equivalent to a world
> readable file.
>
> Making 'none' only look at the world permissions is
> a reasonable way to avoid fooling yourself.

Um.  What if the file is owned by "none", but chmod 0400?  The u+r would
suggest that it would be readable.  But, if only world permissions are
checked, the o-r suggests that it would be be unreadable.

Re: [9front] notes on user none

[ori]

Quoth magma698hfsp273p9f@icebubble.org:
> ori@eigenstate.org writes:
> 
> > One thing that's worth noting: The reason that none
> > only looks at world permissions is that *anyone* can
> > become none with no authentication -- which means
> > that a file readable by none is equivalent to a world
> > readable file.
> >
> > Making 'none' only look at the world permissions is
> > a reasonable way to avoid fooling yourself.
> 
> Um.  What if the file is owned by "none", but chmod 0400?  The u+r would
> suggest that it would be readable.  But, if only world permissions are
> checked, the o-r suggests that it would be be unreadable.

Yes, that's the "not fooling yourself" part.

if none checked permissions as normal, you could
simply do

	auth/none cat file

as any user. if none can read it, so can anyon else.

Re: [9front] notes on user none

[magma698hfsp273p9f]

ori@eigenstate.org writes:

>> Um.  What if the file is owned by "none", but chmod 0400?  The u+r would
>> suggest that it would be readable.  But, if only world permissions are
>> checked, the o-r suggests that it would be be unreadable.
>
> Yes, that's the "not fooling yourself" part.
>
> if none checked permissions as normal, you could
> simply do
>
> 	auth/none cat file
>
> as any user. if none can read it, so can anyon else.

The point is taken, but shouldn't a file owned by none u+r be readable
by none?  I can see how one might fool oneself if a file owned by none
is chmod 0004.  "auth/none cat" can still read it.  But if it's chmod
0400, I would think it should be readable by none.  If you ONLY consult
the world permissions, you're still "fooling yourself"... just in the
opposite direction.

To me, it makes perfect sense for a file to be readable by none if any
of its user, group, or world permissions grant read permission.  That's
the way permissions normally work on Plan 9.  Creating an exception to
those (otherwise regular) rules seems like it's CREATING a way to fool
yourself.

Re: [9front] notes on user none

[sirjofri]

Hello,

I think the system assumes that every user only has access to oneself. 
And since users are secure (glenda can't read my files) it makes sense to 
save the files of user none with user permissions. If none was handled 
like all other users this would effectively give away the security by 
using auth/none. Making the privileges for none like the world user gives 
all other users also the same privileges as the world user, which they 
basically already have (hence it's world).

Auth/none makes you none, but not authenticated. So it's like fake 
access. A nobody, a world user. No longer part of the system. You lose 
privilege.

I'm not saying it's the most elegant design. But try giving nobody access 
to a system that's basically built around user privileges. Try that 
without a user.

TLDR: it makes sense doing it like cwfs currently does and like described 
in the 9 paper. None shouldn't be seen as a user, more like batman, a 
symbol for everyone in the world. Therefore it needs different handling.

sirjofri

(Just my two cents. I'm not a Plan 9 veteran or 9front developer, only a 
user who cares.)