home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / vms / 12697 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  2.7 KB
  1. Path: sparky!uunet!sun-barr!ames!agate!dog.ee.lbl.gov!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (JERRY LEICHTER)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Am I in SYLOGIN?
  5. Message-ID: <9207230644.AA27797@uu3.psi.com>
  6. Date: 23 Jul 92 02:05:48 GMT
  7. Sender: usenet@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 47
  10.  
  11.  
  12.     Anyone know of a simple, fairly fullproof way to determine if an image
  13.     is being run from SYLOGIN.COM or some other known place (step) during
  14.     process creation?
  15.  
  16.     I have an installed privileged application that I want executed during
  17.     the login process, but I don't want users to be able to execute it
  18.     directly.  It does "things" based on an assumed state of that
  19.     process/environment at that time particular time.  Allowing users to
  20.     change their environment (logical names, devices, etc.) and then
  21.     rerunning this image could be a problem in some instances.
  22.  
  23.     Grabing the procedure depth/name from the clidata doesn't seem
  24.     fullproof enough.   Checking the imagecount in the process header
  25.     could work, but I dunno..  Patching loginout (again!) is also too
  26.     messy.    I'd appreciate any ideas/strategies.
  27.  
  28. There's really no way to get the effect you are SPECIFYING in any useful
  29. way.  After all, nothing prevents the user from executing SYLOGIN.COM again
  30. himself!
  31.  
  32. However, if you change the statement of the problem to "execute only once in
  33. a process", there are several possible solutions.  Looked at this way, all
  34. you need is some unremoveable "tag" set on the process that the program can
  35. check to see if it's run before.  An identifier granted to the process would
  36. do the trick.  So would an exec-mode logical name defined in the process
  37. table.  Even the image count is an example of this technique, though it's
  38. one that may be difficult to control.
  39.  
  40. Of course, this prevents a user from running it AGAIN.  Ensuring that it runs
  41. only in a controlled environment just means that you have to be sure that it
  42. runs once in SYLOGIN.COM, which means your SYLOGIN.COM has to be uninterrupt-
  43. able until the program has run.  That's no big deal to accomplish....
  44.  
  45. There's a related problem:  What happens if the user creates a subprocess?
  46. It won't execute normally SYLOGIN.COM, and it won't run your program.  What
  47. should the security policy in that case be?  Is it OK that the program hasn't
  48. run?  Should it be allowed to run?  If not, it's easy to prevent it - one
  49. simple way is to use the exec-mode logical as before, but place it in the
  50. job table.
  51.  
  52. However, the best alternative is to make the privileged application foolproof.
  53. Otherwise, you'll have to worry about oddball cases.  For example, what if
  54. someone uses $CREPRC to start a detached process running the application?
  55.  
  56.                             -- Jerry
  57.  
  58.