[9fans] cpu/file/terminal server of my dream

[9fans] cpu/file/terminal server of my dream

[Wladimir Mutel]

	Greetings,

	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 ?

	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 ?

	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) ?

	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). Is this my wish unreal under Plan9 ? May be
	I should drop my sick enthusiasm and turn back to longly familiar unix?

	Please explain me the Plan9 reality and may be help a little to
	clear my thoughts.

--
mwg@alkar.net

Re: [9fans] cpu/file/terminal server of my dream

[presotto]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

The easiest hackwould be to change /sys/src/9/boot/boopip.c's
connecttcp() to fork off a filter to do what the fcall
module used to.  Look at the funcion filter() in /sys/src/cmd/cpu.c.
It wouldn't necessarily be fast but it would be functional.  If
noone gets to it before I get back to MH (a week or two from now),
I'll do it myself.

[-- Attachment #2: Type: message/rfc822, Size: 1948 bytes --]

From: miller@hamnavoe.demon.co.uk
To: 9fans@cse.psu.edu
Subject: Re: [9fans] cpu/file/terminal server of my dream
Date: Wed, 28 Jun 2000 18:34:16 BST
Message-ID: <E137g9C-000A2o-0V@anchor-post-31.mail.demon.net>

I wrote:
> u9fs will not work as root file system for diskless clients without some
> changes to the kernel.  Since u9fs serves via tcp not il protocol, you would
> have to interpose something like aux/fcall to reconstruct 9p message
> boundaries.

And Steve Kotsopoulos <steve@nevex.com> wrote:

> is this something new with the 3rd edition?
> under 2nd edition I'm using a u9fs fileserver just fine

Yes, the old Plan 9 had fcall(3) stream module within the kernel which
the boot process pushed onto a tcp connection.  This is gone, along
with all kernel stream stuff.

-- Richard Miller

Re: [9fans] cpu/file/terminal server of my dream

[Wladimir Mutel]

miller@hamnavoe.demon.co.uk wrote:

>> u9fs will not work as root file system for diskless clients without some
>> changes to the kernel.  Since u9fs serves via tcp not il protocol, you would
>> have to interpose something like aux/fcall to reconstruct 9p message
>> boundaries.

>> is this something new with the 3rd edition?
>> under 2nd edition I'm using a u9fs fileserver just fine

> Yes, the old Plan 9 had fcall(3) stream module within the kernel which
> the boot process pushed onto a tcp connection.  This is gone, along
> with all kernel stream stuff.

	So, how can we now practically set up a central fs(8) (and preferably
	cpu and auth server there too) ?

--
mwg@alkar.net

Re: [9fans] cpu/file/terminal server of my dream

[rsc]

  is this something new with the 3rd edition?
  under 2nd edition I'm using a u9fs fileserver just fine

yes, it's new.  there's no streams anymore,
and thus no "push fcall".  i've hacked the
support that richard miller described in
before, but it was a while ago and got lost.

russ

Re: [9fans] cpu/file/terminal server of my dream

[miller]

I wrote:
> u9fs will not work as root file system for diskless clients without some
> changes to the kernel.  Since u9fs serves via tcp not il protocol, you would
> have to interpose something like aux/fcall to reconstruct 9p message
> boundaries.

And Steve Kotsopoulos <steve@nevex.com> wrote:

> is this something new with the 3rd edition?
> under 2nd edition I'm using a u9fs fileserver just fine

Yes, the old Plan 9 had fcall(3) stream module within the kernel which
the boot process pushed onto a tcp connection.  This is gone, along
with all kernel stream stuff.

-- Richard Miller

Re: [9fans] cpu/file/terminal server of my dream

[Steve Kotsopoulos]

miller@hamnavoe.demon.co.uk wrote:
> u9fs will not work as root file system for diskless clients without some
> changes to the kernel.  Since u9fs serves via tcp not il protocol, you would
> have to interpose something like aux/fcall to reconstruct 9p message
> boundaries.

is this something new with the 3rd edition?
under 2nd edition I'm using a u9fs fileserver just fine

Re: [9fans] cpu/file/terminal server of my dream

[miller]

Wladimir Mutel <mwg@alkar.net> writes:

	Please explain what could I loss if I set up central file server on
	existing unix by u9fs ? I do not have spare machine to deploy
	full-blown fs(8) there. But, suppose, I do not need its backup
	facility and some other extended features. Can u9fs satisfy me then ?

u9fs will not work as root file system for diskless clients without some
changes to the kernel.  Since u9fs serves via tcp not il protocol, you would
have to interpose something like aux/fcall to reconstruct 9p message
boundaries.  Also u9fs does not use Plan 9 authentication, but only the
(joke) .rhosts file.  So you would be leaving your Unix file system pretty
wide open.

	To say, is there any cpu-server emulator for unixes ?
	It might be a great thing for deploying or migration to Plan9.

Perhaps you should look at Inferno, which does run as an emulator on top
of other operating systems.  See http://www.vitanuova.com for info.

-- Richard Miller

Re: [9fans] cpu/file/terminal server of my dream

[Wladimir Mutel]

miller@hamnavoe.demon.co.uk wrote:

> 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".

	Oh, thank you for correction. I checked mans on 9term and found
	that it is only local. drawterm is the program I indeed wanted to
	mean.

> 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

	Please explain what could I loss if I set up central file server on
	existing unix by u9fs ? I do not have spare machine to deploy
	full-blown fs(8) there. But, suppose, I do not need its backup
	facility and some other extended features. Can u9fs satisfy me then ?
	(provided I am aware of my unix security)

> 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.

	To say, is there any cpu-server emulator for unixes ?
	It might be a great thing for deploying or migration to Plan9.

> 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.

	Oh, but Bell Labs offer to download only that 'poor'
	configuration assuming that local harddisk holds entire main
	filesystem.

	Being on their place, I should in addition offer the following
		separate downloads:

		1. the main file system image, the fs(8) kernel or u9fs
			software, and initial deployment instructions for
			both of them;
		2. boot diskette image or instructions on network booting,
			documents on supported hardware for
			terminal servers, on proper usage of local hardisk,
			etc.
		3. cpu server emulator for unix or windows
			(would be great, heh !)

		However I think I could make two first things by myself,
			using currently available distribution of
			Plan9.

> 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...

	So, does my above proposal lend a newcomer exactly on this
	'proper' way ? To say, 'newcomers' often already have unixes or
	even networks of them. Like we do.

> The real "basic Plan9 setup" -- i.e. the minimal configuration intended to
> export and use services on a network -- uses at least three machines.

> 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.

	Yes, you are about real physical security. I know well that
	somebody can boot from diskette and mount my unix fs anyway, but I
	simply do not consider this case now. Really, local kfs filesystem
	is good only for transient data, but we usually have quite large
	harddisk on every modern PC workstation - can we ever generate
	such amount of transient files or swap per single terminal server
	session ? That is a main question for me.

> 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.

	Yes, this could be a step increasing 'household' usability of
	Plan9.

> 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.

	Ok, thanks. The root of all my grief is that I just do not have
	enough spare computers to deploy 'real' Plan9 on them :>

--
mwg@alkar.net

Re: [9fans] cpu/file/terminal server of my dream

[miller]

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