home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume26 / socket / README < prev    next >
Encoding:
Text File  |  1992-09-07  |  5.9 KB  |  170 lines
  1. Hey Emacs, this is -*- text -*-.
  2.  
  3. This is the README file for Socket-1.1.  
  4.  
  5. For information on how to build and install Socket, read the file
  6. INSTALL.  Please read the file COPYRIGHT about the terms under which
  7. this program is licensed to you.
  8.  
  9.  
  10. What is it?
  11.  
  12. The program Socket implements access to TCP sockets from shell level.
  13. First written for the need to open a server socket and read and write
  14. to the socket interactively for testing purposes, it quickly evolved
  15. into a generic tool providing the socket interface for shell script
  16. and interactive use.
  17.  
  18.  
  19. Client mode
  20.  
  21. In client mode (which is the default) it connects to a given port at a
  22. given host.  Data read from the socket is written to stdout, data read
  23. from stdin is written to the socket.  When the peer closes the
  24. connection or a signal is received, the program terminates.  An
  25. example for this is the following command:
  26.  
  27.     % socket coma.cs.tu-berlin.de nntp
  28.  
  29. This connects to the host coma.cs.tu-berlin.de at the nntp port
  30. (provided these two names can be resolved through gethostbyname(3) and
  31. getservbyname(3)).  The user can now issue commands to the NNTP
  32. server, any output from the server is written to the user's terminal.
  33.  
  34.  
  35. Server mode
  36.  
  37. In server mode (indicated by the "-s" command line switch) it binds a
  38. server socket to the given port on the local host and accepts a
  39. connection.  When a client connects to this socket, all data read from
  40. the socket is written to stdout, data read from stdin is written to
  41. the socket.  For example, the command
  42.  
  43.     % socket -s 3917
  44.  
  45. accepts a connection on port 3917.  
  46.  
  47.  
  48. Restricting data flow
  49.  
  50. It is not always desirable to have data flow in both directions, e.g.
  51. when the program is running in the background, it would be stopped if
  52. it tried to read from the terminal.  So the user can advise the program
  53. only to read from the socket ("-r") or only to write to the socket
  54. ("-w").  Especially when Socket executes a program (see below), it is
  55. important *not* to write to the program's stdin if the program doesn't
  56. read it.  This is the main reason why I added this option.
  57.  
  58.  
  59. Closing connection on EOF
  60.  
  61. For non-interactive use it is not always clear when to close the
  62. network connection; this is still an unsolved problem.  But often it
  63. will be enough to close the connection when some data has been written
  64. to the socket.  In this case the "quit" switch ("-q") can be used:
  65. when an end-of-file condition on stdin occurs, Socket closes the
  66. connection.
  67.  
  68.  
  69. Executing a program
  70.  
  71. An interesting use of a server socket is to execute a program when a
  72. client connects to it.  This done with the "-p" switch.  Stdin,
  73. stdout, and stderr of the program are read from resp. written to the
  74. socket.  Since the server is usually expected to accept another
  75. connection after a connection has been closed, the "loop" switch
  76. ("-l") makes it do exactly that.
  77.  
  78.  
  79. CRLF conversion
  80.  
  81. The Internet protocols specify a CRLF sequence (Carriage Return
  82. Linefeed) to terminate a line, whereas UNIX uses only a single LF.  If
  83. the user specifies the "crlf" switch ("-c"), all CRLF sequences that
  84. are read from the socket are converted to a single LF on output.  All
  85. single LFs on input are converted to a CRLF sequence when written to
  86. the socket.
  87.  
  88.  
  89. Background mode
  90.  
  91. It may be desirable for a server program to run in background. For
  92. that purpose the "background" switch ("-b") is provided.  If it is
  93. set, Socket runs in background, detaches itself from the controlling
  94. tty, closes the file descriptors associated with the tty, and changes
  95. it current directory to the root directory.  It is still possible to
  96. redirect the standard file descriptors to a file.
  97.  
  98.  
  99. Forking child to handle connection
  100.  
  101. Often one wants the server to be able to respond to another client
  102. immediately, even before the connection to the previous client has
  103. been closed.  For this case, Socket can fork a client to handle a
  104. connection while the father process already accepts the next
  105. connection.  To get this behaviour, specify the "-f" option.
  106.  
  107.  
  108. With all these options, a typical server call would look like
  109.  
  110.     % socket -bcfslqp program port
  111.  
  112. Gee, I know that's a lot of options for the standard case, but I
  113. really want to make all these things *optional*.
  114.  
  115.  
  116. Verbose
  117.  
  118. At last, there is also a "verbose" option ("-v"). If this option is
  119. specified, a message is given for each opening and closing of a
  120. connection.  This is convenient especially in interactive use, but can
  121. also provide some kind of logging.  See fingerd.sh for an example.
  122.  
  123.  
  124. WARNING
  125.  
  126. Nothing prevents you from using Socket like this:
  127.  
  128.     % socket -slqp sh 5678
  129.  
  130. THIS IS DANGEROUS! If your machine is connected to the Internet,
  131. *anyone* on the Internet can connect to this server and issue shell
  132. commands to your shell.  These commands are executed with your user
  133. ID.  Some people may think of this program as a BAD THING, because it
  134. allows its user to open his machine for world-wide access to all kinds
  135. of malicious crackers, crashers, etc.  I don't know if I should
  136. consider this as a real security risk or not.  Anyway, it is not my
  137. program which is so dangerous -- anyone with moderate programming
  138. skill can write a something like this.
  139.  
  140. Another problem is that any server program that uses Socket may not be
  141. secure.  I tried to avoid any holes -- especially that one that made
  142. fingerd vulnerable to the attack of Morris' Internet Worm, but I don't
  143. give any warranty.  Also the program run by Socket may have security
  144. holes.
  145.  
  146. I would like to hear your opinion about this topic.  Do you consider it
  147. a security risk to have a program like Socket around?
  148.  
  149.  
  150. Sample programs
  151.  
  152. I included two sample programs, which mimic the behavior of finger(1)
  153. and fingerd(8), implemented as shell scripts using Socket.  rfinger.sh
  154. can only finger remote hosts.  fingerd.sh is RFC 1288 compliant and
  155. can be used independently of inetd(8).
  156.  
  157.  
  158. Comments
  159.  
  160. Please send any comments, suggestions, bug reports etc. to me:
  161.  
  162.     Juergen Nickelsen
  163.     Sekr. FR 5-6
  164.     TU Berlin
  165.     Franklinstr. 28-29
  166.     1000 Berlin 10
  167.     Germany
  168.  
  169.     <nickel@cs.tu-berlin.de>
  170.