Imported Upstream version 1.1.11upstream/1.1.11upstream

1 files changed, 145 insertions, 0 deletions

diff --git a/doc/READMEs/README.netscsid b/doc/READMEs/README.netscsid
new file mode 100644
index 0000000..07c3672
--- /dev/null
+++ b/doc/READMEs/README.netscsid
@@ -0,0 +1,145 @@
+The Remote-SCSI protocol gives you SCSI-Anywhere features.
+
+The protocol used by netscsid is based on rscsi from the cdrtools, developed by
+Joerg Schilling. However, no guarantee for the compatibility or reliability can
+be made. This documentation is based on rscsi documentation from Joerg
+Schilling, but is not identical to the original.
+
+There are three possible ways to control access to the remote users:
+
+	-	Let the remote scsi lib log in as a standard user.
+		In this case netscsid will be called via sh -c netscsid /usr/sbin/netscsid
+		NOTE: In this case, netscsid must be installed suid root. 
+		--- This would need to allow any valid local user to access SCSI ----
+		It could be a security problem.
+
+	-	Log in as root and call netscsid via sh -c netscsid
+		NOTE that this will fore you to allow remote logins as root
+		which is considered to be a security hole.
+
+	-	Create one or more special user(s) that have netscsid
+		as login shell with their own home directory.
+		You then may create special .rhosts files for each user.
+		NOTE: In this case, netscsid must be installed suid root. 
+		**** This is the preferred method ****
+
+To enable remote SCSI via the login shell method you should do the following:
+
+  -	Install netscsid into /usr/sbin. It can be set suid-root if neccessary, see
+    security section below.
+
+	-	Install a file /etc/netscsid.conf and define access rights.
+		Without this file, netscsid will not work at all.
+		The template for this file is: netscsid/netscsid.dfl
+ 
+ - For the special user method, create a user account. This can be done with a
+   frontend like adduser or useradd, if available. The user should have /usr/sbin/netscsid as the login shell.
+   If there is no frontend tool, try this:
+
+   +	Add an entry to /etc/passwd in the form:
+
+      netscsid:x:1999:1000:Tape:/home/netscsid:/usr/sbin/netscsid
+
+      (modify this according to your OS). And don't forget to
+      modify /etc/shadow the way it needs to be on your OS.
+
+   +	Create the home directory for this user, adapt the user/group ownership
+      on this directory.
+  
+  - if you use SSH as the login shell (via appropriate RSH environment variable
+    or a symlink to "rsh" which is the case for many Linux distribution),
+    consult the ssh documentation for details.
+    Note that SSH requires sufficiently powered client/server systems to
+    encrypt/decrypt data in realtime.
+
+  - if you use traditional rsh, add a .rhosts file to this directory to allow
+    access to all users you like (see rsh documentation)
+
+NETSCSID Security:
+
+-	When netscsid starts, it checks if /etc/netscsid.conf exists.
+	If not, it dies.
+
+-	If netscsid is not called by a user listed in /etc/netscsid.conf
+	it dies.
+
+-	To access a SCSI target there must be an entry that lists the user
+	rcsi hast been started from, the hostname and the SCSI target.
+
+	netscsid compares the hostname field in /etc/netscsid.conf 
+	to the peername retrived from STDIN:
+
+	- legal host name		IP connection
+	- "ILLEGAL_SOCKET"		Not an IP socket
+	- "NOT_IP"			Not a socket
+
+NETSCSID Security hints:
+
+-	Do not generally allow other users to see your boot disk via NETSCSID.
+  All people who see this disk may edit your passwd file. This especially
+  applies to suid-root usage. For non-suid-root, check the access permissions.
+
+-	If you are in doubt, only export CD-ROM drives, scanners and similar
+	devices that are not directly security sensitive.
+
+If anybody sees a security hole in my security precautions, please send me a mail!
+
+NETSCSID usage:
+
+-	To use remote SCSI devices you need to know how to access a specific remote
+	SCSI target.
+
+	-	dev=REMOTE:host: or dev=REMOTE:host
+		will allow you to do SCSI bus scanning while you log in as yourself
+
+	-	dev=REMOTE:user@host: or dev=REMOTE:user@host
+		will allow you to do SCSI bus scanning while you log in as "user"
+
+		If you use the setup described above, you should use:
+
+			dev=REMOTE:netscsid@babbel:
+
+		to do SCSI Bus scanning on host babbel
+
+	-	To access a specific SCSI device, you must specify
+		dev=REMOTE:host:<target spec> or dev=REMOTE:user@host:<target spec>
+		<target spec> is the SCSI target specification as it is needed
+		on the remote host
+
+			dev=REMOTE:netscsid@babbel:1,3,0
+
+		Will let you log in as netscsid on host babbel and open Target 3 lun 0
+		on SCSI bus #1
+
+	-	If you use wodim -vv ...., wodim will on startup print some 
+		information about the remote libscg version used for the connection.
+
+-	To be able to use the remote SCSI client code from win32 you need to create
+	a file /etc/passwd with a correct entry for the user you are on win32.
+	Call 'id' to get the right user id.
+	Note that remote SCSI has not yet been tested on Win32.
+
+NETSCSID speed:
+
+-	On a Ultra-10 running Solaris 8, the command overhead time is 400 usec.
+	You may achieve up to 9900 kB/s via a 100MB/s ethernet connection
+	between two of such machines.
+
+-	With 100 MB/s, 12x recording should be no problem.
+
+-	With 10 MB/s, 4x recording is the maximum. Do tests before!
+
+-	Logging into a remote machine and running wodim on the remote machine
+	causes the buffer cache on that machine to be trashed. The main user
+	is disturbed.
+
+-	Doing cdrecording via Remote SCSI causes only the netscsid command with less
+	than 200kB to be needed on the remote machine hosting the CD recorder.
+	The main user on that machine is not disturbed.
+	The buffer cache of the machine running wodim is trashed.
+
+-	It is desirable to use a Burn-Proof recorder to make sure that network
+	load will not cause buffer underruns.
+
+
+-	USER= test and test for hostname are using a pattern matcher.