9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Anthony Martin <ality@pbrane.org>
To: 9front@9front.org
Subject: [9front] notes on user none
Date: Fri, 22 Jan 2021 15:44:05 -0800	[thread overview]
Message-ID: <YAtjRdBuMpZF1U8y@alice> (raw)

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

             reply	other threads:[~2021-01-23  0:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22 23:44 Anthony Martin [this message]
2021-01-23  9:45 ` sirjofri
2021-01-23 14:02   ` hiro
2021-01-23 14:13 ` cinap_lenrek
2021-01-23 21:31 ` ori
2021-01-24  6:33   ` magma698hfsp273p9f
2021-01-25 19:44     ` ori
2021-01-31 21:42       ` magma698hfsp273p9f
2021-02-01 22:06         ` sirjofri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YAtjRdBuMpZF1U8y@alice \
    --to=ality@pbrane.org \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).