home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0059.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  4.7 KB  |  100 lines
  1. Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
  2.  
  3. Peter da Silva writes:
  4. > Because the more things you can access via the open() system call, the more
  5. > powerful an environemnt you have. For example, older programs become able to
  6. > access more data sources and sinks without modification or recompiling.
  7.  
  8. No. If you need a kludge to support non-UNIXy programs, use /dev/fd.
  9. It's vastly simpler than any super-open() could ever be, and it achieves
  10. your goal of letting older programs open network connections et al.
  11.  
  12. > For a concrete example, in AmigaDOS this expectation is taken further:
  13.  
  14. Fine. If you think that AmigaDOS features are appropriate for POSIX
  15. standardization, then implement them in a UNIX system and wait for their
  16. obvious advantages to win everyone over.
  17.  
  18. > > Let's move on to the supposed simplicity of super-open() for programmers.
  19. > > Since when was it difficult to create, e.g., network connections with the
  20. > > BSD syscalls?
  21. > Not very, but it's hard to create one from your ".mailrc" file.
  22.  
  23. Hmmm? There are many programs running around (e.g., clientserver) which
  24. do the same thing for network connections that the shell (via < and >)
  25. does for the filesystem.
  26.  
  27. > > also bloating the kernel for something which the vast majority of
  28. > > programs will never use.
  29. > The challenge is on... let's look though my System III (because it's older
  30. > and therefore more "pure") Xenix manual:
  31. > accton, awk, bdiff, bfs, chgrp, chmod, chown, cmp, comm, cp, cron, cu, diff,
  32. > diff3, ed, finger, join, ln, look, lpq, lpr, mail, make, more (and less),
  33. > mv, nohup, pr, rm, sdiff, tee, touch, and uucp (etc).
  34.  
  35. bdiff, cmp, comm, diff, diff3, join, look, more, nohup, pr, sdiff, tee,
  36. and touch can be written to work with file descriptors under v7. Under
  37. BSD, the syscalls for working with descriptors are more complete, so you
  38. can do chgrp, chmod, chown, etc. without explicit filenames. I also
  39. wonder what sense it makes to do a chmod on /dev/tcp/uunet.uu.net/ftp---
  40. how are you going to keep track of the modes on *every single possible
  41. network connection*? Where's your implementation which shows us what the
  42. issues are?
  43.  
  44. Three of the programs you list---ln, mv, rm---are red herrings: of
  45. course they work with filenames in the filesystem, because their job is
  46. to manipulate those names! (They fall under the category of ``a few
  47. specialized tools'' that I mentioned.) And do you have a system where
  48. accton works over the network? If so I'm sure crackers love your system.
  49.  
  50. finger, lpq, lpr, mail, and uucp are (relatively) complex tools for
  51. accessing system databases. Fortunately, they can all be written as
  52. combinations of simpler tools, some of which are dedicated to opening
  53. files and some of which stick to file descriptors. That's the UNIX way.
  54.  
  55. Finally, I have to agree with you that awk, ed, and make would have a
  56. tough time without open(). Like sh, they're all programming languages,
  57. and like sh they make it very easy for the programmer to open a file.
  58. So maybe super-open() would make these tools more useful. I doubt it.
  59. For the same reason that they're powerful enough to open files, they're
  60. powerful enough to execute arbirtary programs, and those arbitrary
  61. programs could open network connections just as easily as open() could.
  62.  
  63. > This list also
  64. > brings up the question of security: all UNIX security is based on access to
  65. > files. Adding new ways to create file descriptors involves duplicating all
  66. > this security and causing a separate source of kernel expansion.
  67.  
  68. Hardly. Adding new ways to create file descriptors involves thinking up
  69. new ways to deal with security. Filesystem security is utterly
  70. inappropriate for network connections, for example. Adding a
  71. super-open() means kludging these new security mechanisms into a
  72. protection system designed only for files.
  73.  
  74. > > Finally, let's consider super-open()'s advantages for users. Certainly
  75. > > it'd be nice for a user to be able to type something like, say,
  76. > >    % cat #13@athena.mit.edu
  77. > More like "cat /dev/telnet/athena.mit.edu/13".
  78.  
  79. Whatever. The shell can still do it!
  80.  
  81. > then what do you do when you want to access this from "awk", or create a
  82. > (sumbolic) link to it called "/dev/weather"?
  83.  
  84. The pure solution is to have every program keep a file descriptor around
  85. for talking to the shell. Then requests for opening files can be
  86. shuttled down that descriptor. The problem reduces once again to a small
  87. matter of shell programming.
  88.  
  89. Less pure solutions involve /dev/fd or perhaps what Convex calls
  90. ``watchdogs.'' Both of these are far cleaner mechanisms than
  91. super-open(), and since they've at least been considered by the market,
  92. they'd be far more appropriate for standardization.
  93.  
  94. ---Dan
  95.  
  96. [ Apologies to anyone who has seen multiple copies of Dan's postings. -- mod ]
  97.  
  98. Volume-Number: Volume 26, Number 70
  99.  
  100.