9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Dave Eckhardt <davide+p9@cs.cmu.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] Re: First-timer help
Date: Sun, 17 Jul 2005 18:13:09 -0400	[thread overview]
Message-ID: <21121.1121638389@piper.nectar.cs.cmu.edu> (raw)
In-Reply-To: <42DAA30C.9090800@moseslake-wa.com>

> I then ran "auth/changeuser john" and tried to set my password,
> but I got a "permission denied" error.  Help?

My apologies for the vague answer, but: every time I've run
auth/changeuser (running as bootes on my auth/fossil/venti file
server) I've got a "permission denied" error which appears to be
harmless, since the accounts are created and people can log in.
I haven't chased it down beyond that.

> And why do you have to reboot in order to change users?
> UNIX has had that from the beginning, and I don't see any
> reason to drop it.

Plan 9 was designed around a particular distributed system
architecture (see the "Plan 9 From Bell Labs" paper at
http://cm.bell-labs.com/sys/doc/index.html).  There are
basically three kinds of machine:

* critical infrastructure, such as authorization and reliable file
  storage, which define identity and trust for the multi-user
  computing environment--these are typically accessible by only
  trusted system administrators and located in physically secure
  environmentally-controlled locations,

* shared "CPU servers", whose configuration, policies, and hardware
  are owned by the system administrators, but which can be used
  in a restricted fashion by multiple users simultaneously,

* public-access "terminals", which will allow any user to boot
  them running any code--think of a standard PC, where whoever
  sticks a floppy into the drive can do anything they wish.

Other models are possible.  For example, Amoeba was designed
for "processor pools", racks of CPU servers each one of which
was used by one user at a time.

In order to have multiple users running on a public-access
terminal, you have to define what you would mean by that,
which isn't easy.  Who should own a particular serial line
or USB port?  If Alice boots a kernel she just wrote, should
Bob trust it to keep his password secret?  Should Bob be able
to reboot the machine to use a different kernel if Alice is
running some long computation?

These questions are architecturally answered for Plan 9 file
servers (nobody logs in), and CPU servers (people can log in,
but not reboot, modify configuration, or control hardware).
The answer for terminals is "one person owns the machine at
a time and can do anything to it".  Rebooting is a simple
way to ensure that *everything* on the machine belongs to
one user at a time.

Dave Eckhardt


      parent reply	other threads:[~2005-07-17 22:13 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-17 18:27 [9fans] " John Floren
2005-07-17 18:26 ` Gorka guardiola
2005-07-17 19:18   ` John Floren
2005-07-17 19:20     ` Russ Cox
2005-07-17 23:12       ` Charles Forsyth
2005-07-18  9:23         ` Martin C. Atkins
2005-07-18 10:45           ` lucio
2005-07-18 18:24             ` Jack Johnson
2005-07-19  6:01             ` Martin C. Atkins
2005-07-19 13:29               ` Axel Belinfante
2005-07-19 13:57               ` Ronald G. Minnich
2005-07-19 16:11                 ` Martin C. Atkins
2005-07-19 15:38               ` Charles Forsyth
2005-07-19 16:12                 ` Skip Tavakkolian
2005-07-19 16:39                 ` Martin C. Atkins
2005-07-21  2:30                 ` Tim Newsham
2005-07-20  1:43               ` Brian L. Stuart
2005-07-18 13:08           ` Steve Simon
2005-07-21  2:17             ` Tim Newsham
2005-07-21  4:34               ` arisawa
2005-07-21  2:11         ` Tim Newsham
2005-07-21  2:57           ` Ronald G. Minnich
2005-07-22  9:44             ` Richard Miller
2005-07-22  9:49               ` Charles Forsyth
2005-07-22 15:09                 ` Gorka guardiola
2005-07-22 14:14               ` Wes Kussmaul
2005-07-22 15:36               ` David Leimbach
2005-07-22 18:13                 ` jmk
2005-07-23  3:30                 ` LiteStar numnums
2005-07-23 16:19                   ` Ronald G. Minnich
2005-07-21 16:12           ` Dave Eckhardt
2005-07-21 16:23             ` Russ Cox
2005-07-21 17:33             ` Wes Kussmaul
2005-07-21 18:13             ` Tim Newsham
2005-07-22  6:16               ` Dave Eckhardt
2005-07-22  6:20                 ` Charles Forsyth
2005-07-21 23:00             ` Ronald G. Minnich
2005-07-22  1:28               ` David Leimbach
2005-07-22  1:48               ` Russ Cox
2005-07-22  3:54                 ` Ronald G. Minnich
2005-07-22  5:57                   ` lucio
2005-07-17 19:20     ` andrey mirtchovski
2005-07-17 19:47       ` John Floren
2005-07-17 19:44         ` andrey mirtchovski
2005-07-17 20:17           ` John Floren
2005-07-17 20:20             ` andrey mirtchovski
2005-07-17 20:58               ` Russ Cox
2005-07-17 19:45         ` Christopher Nielsen
2005-07-17 23:17         ` Charles Forsyth
2005-07-18  0:33           ` Dave Lukes
2005-07-18  7:31             ` lucio
2005-07-18 15:24             ` Jack Johnson
2005-07-18 15:33               ` David Leimbach
2005-07-18 13:51         ` Ronald G. Minnich
2005-07-18 15:54           ` arisawa
2005-07-18 16:46             ` Jack Johnson
2005-07-17 19:29     ` Tim Wiess
2005-07-19  0:33     ` arisawa
2005-07-19  1:04       ` arisawa
2005-07-17 18:26 ` andrey mirtchovski
2005-07-17 18:30   ` andrey mirtchovski
2005-07-17 22:13 ` Dave Eckhardt [this message]

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=21121.1121638389@piper.nectar.cs.cmu.edu \
    --to=davide+p9@cs.cmu.edu \
    --cc=9fans@cse.psu.edu \
    /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).