2
Installation
This is described in the Inferno User's Guide
; however, the actual experience can differ. As is usual when installing a new system, one knows nothing and has to deal with fairly difficult commands. The goal is to run clients and servers.
Server
lib/srv
starts various daemons. If they are running, the system is termed a server. There are, however, several different server configurations:
| Signer | a so called certification authority, necessary to construct secure connections. If this is installed as described in the User's Guide, it might have to be run as root so that keydb can be manipulated. In any case, it is run by a unique host user. |
| File Server | permits access to its file system. If this is installed as described in the User's Guide, it would have to be run as inferno so that usr/inferno/keyring/default can be written. |
| MPEG Server | is supposed to deliver MPEG streams for video on demand. |
| Mail Server | is supposed to administrate electronic mail. |
Client
A client uses resources provided by servers. Normally the same certification authority must identify client and server.
Network
A network can contain many clients and servers; however, there should be a single signer.
For testing, a machine can be run stand-alone or in loopback mode as a signer and a client at the same time. This is accomplished most easily (if insecurely) with Windows 95 as a host.
Linux: 32 MB main memory, 130 MB disk space recommended. After installation the system occupies about 32 MB, including the files for the other platforms which could be removed. The manual recommends RedHat Linux 4.0, kernel 2.0.18; I have used InfoMagic Slackware, kernel 2.0.0, and S.u.s.e. kernel 2.0.32.
Windows: 16 MB main memory, 50 MB disk space recommended. After installation the system occupies about 23 MB with 2300 files. There has to be a TCP/IP protocol.
Users
The examples use inferno as a password throughout.
UNIX: Create a user inferno in group inferno, log in as inferno and install in /usr/inferno if possible. I install in /usr/inferno/Base to link subsystems to that.
Windows 95: Log in as user inferno. Install wherever.
Windows NT: Log in as Administrator. Install wherever. The permissions are eventually set wide open.
Installing the CD
UNIX: Log in as inferno and do the following:
$ /cdrom/setup.sh /usr/inferno
Unwinding the tar file, this will take a while!
tar: Could not create directory inferno: Permission denied
ERROR: tar failed, exit 6
The error may not happen. Then, as root, protect keydb:
# cd /usr/inferno
# chown -R root.inferno keydb
# chmod -R go= keydb
Windows: Run setup from the Inferno CD. Afterwards run the script permfix.bat so that no write protection remains; the directories appl/mux and appl/svc are missing. Installation happens under InstallShield and can be undone.
Windows NT: If NTFS was used, select Properties/Ownership in Explorer for the installation point and make sure that Administrators owns it. With Properties/Permissions add the (predefined) user Everyone with Full Control for the entire tree or the emulator will not start.
UNIX: As root, add the contents of services.txt to /etc/services or NIS.
Windows 95: Check in \windows\services that the new entries only use free ports.
Windows NT: Check in \winnt\system32\drivers\etc\services that the new entries only use free ports.
Inferno requires the following ports (i.e., it cannot run without TCP/IP or winsock):
| styx | 6666/tcp | file service | |
| mpeg | 6667/tcp | MPEG stream | |
| rstyx | 6668/tcp | remote execution service | |
| infdb | 6669/tcp | database gateway | |
| infweb | 6670/tcp | web server | |
| infsigner | 6671/tcp | signer | |
| infcsigner | 6672/tcp | countersigner | |
| inflogin | 6673/tcp | login | |
| virgil | 2202/udp | name server (remote cs) |
Define data for lib/cs
In the Inferno tree in services/cs/db the DNS names of the servers must be entered (in Windows with WordPad). These name can be found later through cs
or virgil
:
$MPEG perky.cs.rit.edu
$SIGNER perky.cs.rit.edu
$FILESERVER perky.cs.rit.edu
$MAILSERVER perky.cs.rit.edu
Linux: Start the emulator
from a shell as Linux/386/bin/emu.
Windows: Start the emulator
from the start menu. If the emulator window disappears, add the switch -s to the shortcut to see the system error message in a panel.
In the emulator start the server suite:
Inferno Release 1.0 Build 1 main (pid=4293996589) interp
Initialize Dis: /dis/sh.dis
perky$ lib/srv
srv: initialize services
cs: tcp!*!6672 -> /net/tcp/clone 6672
cs: tcp!*!6673 -> /net/tcp/clone 6673
cs: tcp!*!6666 -> /net/tcp/clone 6666
cs: tcp!*!6671 -> /net/tcp/clone 6671
cs: tcp!*!6668 -> /net/tcp/clone 6668
cs: udp!*!2202 -> /net/udp/clone 2202
perky$
Terminate the emulator with control-C; terminate input with control-D. Backspace should work.
lib/srv
interprets /services/namespace with newns
, starts the connection server lib/cs
and then various daemons:
| provides certificates for authentication, e.g., to use file service. |
| daemons for identification in set-top-boxes. |
| name server daemon which connects to lib/cs. |
file service
| a thread in lib/srv |
remote execution service
| a thread in lib/srv |
Unless other arrangements are made the server suite has to be restarted when the emulator is started again.
The signer must be able to read and write keydb. Other users must not have access to this area.
UNIX: The installation instructions require root to operate the signer.
Windows: There are no restrictions. Even with NTFS all users have full access to keydb.
emu
can run another program in place of /dis/sh.dis
if its path in the Inferno tree is specified as an argument. From the sources of lib/srv a program ca.b
can be derived that loads /services/namespace, startslib/cs, spawns a thread that passes queries at inflogin to an instance of lib/logind, and finally executes a shell.
Under Linux a user ca can own keydb. This user can operate a relatively secure signer.
Within emu a new user xyzzy has to be created on which all certificates depend:
$ emu CA
Inferno Release 1.0 Build 1 main (pid=306) interp
Initialize Dis: CA
ca: build /services/namespace
ca: start connection server
ca: announce inflogin for /dis/lib/logind.dis
cs: tcp!*!6673 -> /net/tcp/clone 6673
perky$ changelogin xyzzy
new account
password: inferno
expires [DDMMYYYY, return = 23031998]: 31121999
free form info [return = ]: Inferno Signer
change written
perky$ netstat
tcp/0 ca 0.0.0.0!6673 0.0.0.0!0 Announced
| manipulates the binary password file keydb/password on the signer. |
drwxr-x ca .
lrwxrwx ca Base
lrwxrwx ca CA
drwxr-x inferno chan
drwxr-x inferno dev
drwxr-x inferno dis
lrwxrwx inferno dis/changelogin.dis
drwxr-x inferno dis/lib
lrwxrwx inferno dis/lib/bufio.dis
lrwxrwx inferno dis/lib/createsignerkey.dis
lrwxrwx inferno dis/lib/cs.dis
lrwxrwx inferno dis/lib/daytime.dis
lrwxrwx inferno dis/lib/logind.dis
lrwxrwx inferno dis/lib/newns.dis
lrwxrwx inferno dis/lib/password.dis
lrwxrwx inferno dis/lib/random.dis
lrwxrwx inferno dis/lib/readdir.dis
lrwxrwx inferno dis/lib/ssl.dis
lrwxrwx inferno dis/ls.dis
lrwxrwx inferno dis/netstat.dis
lrwxrwx inferno dis/ps.dis
lrwxrwx inferno dis/sh.dis
-rwxr-x inferno emu
drwx--- ca keydb
-rw---- ca keydb/password
-rw---- ca keydb/signerkey
drwxr-x inferno n
drwxr-x inferno n/client
drwxr-x inferno n/remote
drwxr-x inferno n/ssl
drwxr-x inferno net
drwxr-x inferno nvfs
drwxr-x inferno prog
drwxr-x inferno services
drwxr-x inferno services/cs
-r--r-- inferno services/cs/db
-r--r-- inferno services/namespace
The system mostly contains symbolic links that use Base to point to the root of a completely installed Inferno CD. After the system is unpacked Base has to be fixed, CA has to point to ca.dis, and an empty file keydb/password has to be owned by ca.
emu is a trivial UNIX shell script to simplify starting the emulator:
exec Base/Linux/386/bin/emu -r`pwd` "$@"
The file server must be able to read and write his usr/<name>/keyring. Other users must not have access to this area.
UNIX: If the file server is operated as root, it assumes the identity of the last authenticated user (if this user is known on the host), even if other users are authenticated for other accesses. If a user other than root operates the file server, identities are not changed. Basically this means that a realistic safe use is not feasible.
Windows NT: The file server handles identities much like UNIX. There are additional problems because user names look like system\name and don't match the home directories.
As one should execute lib/srv, the file server more or less has to be operated by the same identity as the signer. If at least one authenticated user wants private files the file server has to be operated by root under UNIX.
From the sources of lib/srv a program fs.b
can be derived that loads /services/namespace, startslib/cs, spawns a thread that answers queries at styx with threads for file service with private name spaces, and finally executes a shell.
Within emu the user that started emu must obtain a certificate from the signer:
# emu FS
Inferno Release 1.0 Build 1 main (pid=828) interp
Initialize Dis: FS
fs: build /services/namespace
fs: start connection server
fs: announce styx
cs: tcp!*!6666 -> /net/tcp/clone 6666
perky$ getauthinfo default
use signer [perky]:
remote user name [root]: xyzzy
password: inferno
save in file [no]: yes
cs: tcp!perky!6673 -> /net/tcp/clone 131.173.161.211!6673
perky$ netstat
tcp/0 root 0.0.0.0!6666 0.0.0.0!0 Announced
| contacts logind, creates a certificate, and stores it in usr/<name>/keyring/<argument> as text. The file server's certificate is at default and the certificate for mount net!<machine> is at net!<machine>. |
drwxr-x inferno .
lrwxrwx inferno Base
lrwxrwx inferno FS
drwxr-x inferno chan
drwxr-x inferno dev
lrwxrwx inferno dis
-rwxr-x inferno emu
drwxr-x inferno licensedb
drwxr-x inferno n
drwxr-x inferno n/client
drwxr-x inferno n/remote
drwxr-x inferno n/ssl
drwxr-x inferno net
drwxr-x inferno nvfs
drwxr-x inferno prog
drwxr-x inferno services
drwxr-x inferno services/cs
-r--r-- inferno services/cs/db
-r--r-- inferno services/namespace
drwxrwx inferno tmp
drwxr-x inferno usr
drwxr-x axel usr/axel
drwxr-x axel usr/axel/dis
drwx--- axel usr/axel/keyring
-r--r-- axel usr/axel/namespace
drwxr-x axel usr/axel/ns
-rw-r-- axel usr/axel/ns/fs
-r--r-- axel usr/axel/wmsetup
drwxr-x inferno usr/inferno
drwxr-x inferno usr/inferno/dis
drwx--- inferno usr/inferno/keyring
-r--r-- inferno usr/inferno/namespace
drwxr-x inferno usr/inferno/ns
-rw-r-- inferno usr/inferno/ns/fs
-r--r-- inferno usr/inferno/wmsetup
drwxr-x nobody usr/nobody
drwxr-x root usr/root
drwx--- root usr/root/keyring
root or inferno should operate this system and inferno or axel should be clients.
usr/<name>/ns/fs contains commands for newns
, which create a private namespace which the file server will make available for the user:
bind -a /dis /usr/axel/dis
bind -rc /usr/axel /
The CD is installed as if it were a server. However, services/cs/db would normally point to foreign systems.
The client must be able to read and write his usr/<name>/keyring. Other users must not have access to this area.
| contains the user name for the current process group. It is obtained from the host system and can only be changed by this original user, apparently only in the first process. |
Basically, the client has the same problem as does the file server: if you want to be an identified user and access the local system, you have to start the client as root and set /dev/user to the proper identity.
From the sources of lib/srv a program client.b
can be derived that loads /services/namespace, starts lib/cs, asks for a user name, enters it into /dev/user, changes to the home directory and tries to build ns/client there (which would normally connect to a file server), and finally executes a shell.
Within emu a certificate must be obtained from the signer:
# emu Client
Inferno Release 1.0 Build 1 main (pid=1006) interp
Initialize Dis: Client
client: build /services/namespace
client: start connection server
user: inferno
perky$ getauthinfo net!$FILESERVER
use signer [perky]:
remote user name [inferno]:
password: inferno
save in file [no]: yes
cs: tcp!perky!6673 -> /net/tcp/clone 131.173.161.211!6673
perky$ ls keyring
keyring/net!$FILESERVER
perky$ mount net!$FILESERVER /n/fs
cs: tcp!perky!6666 -> /net/tcp/clone 131.173.161.211!6666
perky$ bind /n/fs/dis /dis
mount
connects the existing directory /n/fs with the root of the file server over an authenticated connection, i.e., with the identity of the certificate on the file server. bind
hides the local directory /dis with the imported directory /n/fs/dis, i.e., commands are then obtained from the file server. These kind of commands would be entered in ns/client.
drwxr-x inferno .
lrwxrwx inferno Base
lrwxrwx inferno Client
drwxr-x inferno chan
drwxr-x inferno dev
drwxr-x inferno dis
lrwxrwx inferno dis/bind.dis
lrwxrwx inferno dis/cat.dis
lrwxrwx inferno dis/cd.dis
lrwxrwx inferno dis/chmod.dis
lrwxrwx inferno dis/echo.dis
lrwxrwx inferno dis/getauthinfo.dis
drwxr-x inferno dis/lib
lrwxrwx inferno dis/lib/bufio.dis
lrwxrwx inferno dis/lib/cs.dis
lrwxrwx inferno dis/lib/daytime.dis
lrwxrwx inferno dis/lib/filepat.dis
lrwxrwx inferno dis/lib/login.dis
lrwxrwx inferno dis/lib/newns.dis
lrwxrwx inferno dis/lib/pipe.dis
lrwxrwx inferno dis/lib/random.dis
lrwxrwx inferno dis/lib/readdir.dis
lrwxrwx inferno dis/lib/ssl.dis
lrwxrwx inferno dis/lib/string.dis
lrwxrwx inferno dis/lib/workdir.dis
lrwxrwx inferno dis/ls.dis
lrwxrwx inferno dis/mkdir.dis
lrwxrwx inferno dis/mount.dis
lrwxrwx inferno dis/nsbuild.dis
lrwxrwx inferno dis/ps.dis
lrwxrwx inferno dis/pwd.dis
lrwxrwx inferno dis/rm.dis
lrwxrwx inferno dis/sh.dis
lrwxrwx inferno dis/unmount.dis
-rwxr-x inferno emu
drwxr-x inferno n
drwxr-x inferno n/client
drwxr-x inferno n/fs
drwxr-x inferno n/remote
drwxr-x inferno n/ssl
drwxr-x inferno net
drwxr-x inferno nvfs
drwxr-x inferno prog
drwxr-x inferno services
drwxr-x inferno services/cs
-r--r-- inferno services/cs/db
-r--r-- inferno services/namespace
drwxrwx inferno tmp
drwxr-x inferno usr
drwxr-x axel usr/axel
drwx--- axel usr/axel/keyring
drwxr-x inferno usr/inferno
drwx--- inferno usr/inferno/keyring