9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: miller@hamnavoe.demon.co.uk
To: 9fans@cse.psu.edu
Subject: Re: [9fans] cpu/file/terminal server of my dream
Date: Tue, 27 Jun 2000 10:39:12 +0100	[thread overview]
Message-ID: <E136ryQ-0007x5-0Y@anchor-post-34.mail.demon.net> (raw)

Wladimir Mutel <mwg@alkar.net> writes:

	Suppose I have basic Plan9 setup (9pcdisk).
	I log on to its terminal server under my own user name.

	How then do I give my file- and cpu-services to my unix colleagues,
	provided they have 9term and wish to connect to my host to know some
	more about Plan9 ?

I think what your Unix colleagues want is not 9term but drawterm(8),
"a program that users of non-Plan 9 systems can use to establish graphical
cpu(1) connections with Plan 9 CPU servers".

The normal way to export the cpu and auth services needed by drawterm
is to configure your machine as a cpu server.  It is possible to make a
Plan 9 terminal listen on cpu and ticket (authentication) ports, but this
is not the way Plan 9 is designed to be used.  See below...

	How then do I make a secure file server of my local harddisk (with
	some use restrictions for disk/kfscmd)? Now anybody can log on locally to
	terminal server under any name and make anything with local filesystem
	with kfscmd ! Nothing similar is observed for any unix installation,
	why is it so insecure under Plan9 ?

A normal "production" Plan 9 network is more secure than the average Unix
system, because of the separation of file service, cpu service, and user
access onto separate machines.  A Plan 9 file server (presumably kept behind
a locked door) exports only one service to the outside world, which is
subject to authentication by a trusted machine.  You can't log in to the
file server remotely or exploit flaws in obscure network services to run
malicious programs there -- in fact the file server can't run anything which
is not built into its kernel.  A cpu server is a shared system, but can
only be accessed via an external connection authenticated by a trusted
machine, with no superuser or setuid to break through the separation
between user resources, and no chance of bypassing file protections by
accessing disk devices directly because they are attached to the file server.
Finally, the only machine under physical control of the user is the Plan 9
terminal, which is a intended as a single-user resource, not a server; its
local disk, if any, is for swapping and cacheing of temporary copies of files.
Subsequent users "login" to a terminal by rebooting from the network, so
they know they are talking to a fresh instance of Plan 9 and not to a
login spoofing program which a previous user has left running to collect
passwords...

The real "basic Plan9 setup" -- i.e. the minimal configuration intended to
export and use services on a network -- uses at least three machines.
The stand alone terminal with a local kfs is a compromise, and doesn't
pretend to be secure.  I would point out that security is mostly illusory
for just about any stand alone machine which is physically accessible,
whatever the operating system.  Most Unix PC's can be booted in single
user mode, or booted from a floppy with a specially doctored kernel.
I haven't used Solaris lately, but I know I used to be able to put a Sun
into super-user mode in a few seconds by using the ROM monitor to alter
a few bytes in kernel memory.

	I know I need to rebuild a kernel, but among different kernel
	configurations I did not find one I want.
	Really, what if I do not want, or simply am unable, to dedicate spare
	headless machine for file serving (for example, since not having one) ?

Yes, it can be useful to make a cpu server act as a file server too;
despite the above sermon I admit that I do it sometimes.  The distributed
system allows for this by using exportfs(4) -- just rename _il17008 and
_tcp564 in /rc/bin/service to il17008 and tcp564.  But this doesn't
provide authentication, and exportfs is rather inefficient and tends
to run out of resources.  So I've implemented a kfscmd which tells kfs
to export a fully authenticated file service to the network.  Russ Cox is
currently trying this out, so my changes may find their way into the
standard system; if not, I can post them to 9fans.

	I just have a strongest wish for single host to be file and cpu
	server at the same time, and to become also a terminal server
	whenever whoever wants to log on it locally (like X-server with xdm).
	(and to log off it by stopping terminal server but keeping cpu and
	file servers running).

Some years ago, Vadim Antonov <avg@postman.ncube.com> posted changes to
make a cpu server act as a terminal for successive users -- init(8) reads
and authenticates a user name, and control of resources is split between
#c/termowner (screen, keyboard, mouse and floppy) and #c/hostowner
(everything else).  So this is feasible too.  But I think it's worthwhile
to spend some time getting to know Plan 9 as it is before rushing to make
it more like Unix.

-- Richard Miller


             reply	other threads:[~2000-06-27  9:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-27  9:39 miller [this message]
2000-06-27 12:30 ` Wladimir Mutel
  -- strict thread matches above, loose matches on Subject: below --
2000-06-29 17:50 presotto
2000-06-28 18:40 rsc
2000-06-28 17:34 miller
2000-06-29 16:49 ` Wladimir Mutel
2000-06-28 15:56 miller
2000-06-28 16:13 ` Steve Kotsopoulos
2000-06-26  9:01 Wladimir Mutel

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=E136ryQ-0007x5-0Y@anchor-post-34.mail.demon.net \
    --to=miller@hamnavoe.demon.co.uk \
    --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).