home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / wizards / 3797 < prev    next >
Encoding:
Internet Message Format  |  1992-09-04  |  3.4 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!ub!toz!rchandra
  2. From: rchandra@toz.buffalo.ny.us (Dr. R. Chandra)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: correcton: restrictin
  5. Message-ID: <gate.swaJqB1w165w@toz.buffalo.ny.us>
  6. Date: 3 Sep 92 16:42:02 GMT
  7. Lines: 62
  8. X-Maildoor: WaflineMail 1.00r
  9.  
  10. > In article <928@gofish.Stars.Reston.Unisys.COM> dymm@cards.com (David
  11. > Dymm) writes:
  12. > >I would like to set up a restricted directory tree
  13. > >on my Sun 4 system.  That is, certain users, when logging on,
  14. > >would be placed into accounts that would be located in a
  15. > >directory tree that would not have access to the rest of
  16. > >the system directory structure. ...
  17. >
  18. > The way my college did this was to create the restricted users
  19. > in the 'peon' group-id.
  20. > >All restricted directories were owned by group peon but with NO
  21. > permissions.
  22. > Correction: no GROUP permissions
  23.  
  24. I like this application.  On a UNIX system which I am writing software
  25. for, I need root access on occasion, but it's a pain to inform me when
  26. the password changes (for doing su(1) for instance), so I have a little
  27. suid binary that does setuid(2) and setgid(2) to the proper values and
  28. exec(2)s a shell.  Since it has to be owned by root, and for me to
  29. execute it, it has to be "world" executable, and giving everyone on the
  30. system a root shell would be a very Bad Thing, it is tucked away in a
  31. subdirectory of my home directory where owner (me) has all permissions
  32. and every other field has no permissions (the key one being search, or
  33. "x").  Therefore, I am the only one besides root who has perms to do
  34. anything to it.  The only difference then is the utmp entry.
  35.  
  36. > That way, owner and all other have access but NOT peon.
  37. > Although this is contradictory to the intent of permission GRANTING
  38. > vs. permission denial, it works.
  39. >
  40. > ex: /bin2 had commands that were not for peon use (moved over from
  41. > /bin)
  42. > dr-x---r-x   2 bin      peon         1664 Aug 26 16:14 /bin2
  43. [...]
  44. > As already mentioned an other postings, using the restricted shell
  45. > also helps.
  46. > I'm not sure if it was fixed, but there was a bug in how the shell
  47. > determined if it was restricted or not.
  48. > The old code checked for an 'r' in argv[0].  Anywhere in argv[0].
  49. > This bit me when a login for 'smart' (a teaching program) used
  50. > a C program that used 'system' to do something.
  51. > The subshell inherited the argv[0] of 'smart' and since it contained
  52. > an 'r', it went into restricted shell mode.
  53. > The workaround was to alter argv[0] to something without any 'r'.
  54.  
  55. Ick!  I didn't know about that one.  Thanks!  I'll watch out for it now.
  56.  
  57. > Set root is tricky becuase you need hard links for all things in /dev,
  58. > /tmp and other things that are below the new root.
  59.  
  60. Oh, really?  Granted, it is convenient from a system management
  61. viewpoint (should anything in the true /dev/ change), but what's wrong
  62. with mknod(1) in the "new root?"  All's the system needs is the major
  63. and minor numbers from the inode, regardless of where in the directory
  64. tree it gleans this info from.  And there's nothing inherently special
  65. about /tmp either...just that most schemes mount a large disk or disk
  66. partition on it.  That has definite advantages in a system failure (who
  67. cares if fsck can't fix it?  Just mkfs with it and it'll be just fine).
  68. So therefore, if the operative word is "need," I think not.  Desirable,
  69. probably.
  70.  
  71.  * Q-Blue v0.7 [NR] *                                                                                                                    
  72.