home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / wizards / 3711 < prev    next >
Encoding:
Text File  |  1992-08-27  |  2.4 KB  |  73 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!krfiny!jeffj
  3. From: jeffj@krfiny.uucp (J. Jonas)
  4. Subject: correcton: restricting users
  5. Message-ID: <1992Aug27.180317.16677@krfiny.uucp>
  6. Summary: use group id to deny access
  7. Organization: Jeff's house of computer pieces
  8. Date: Thu, 27 Aug 1992 18:03:17 GMT
  9. Lines: 62
  10.  
  11.  
  12. In article <928@gofish.Stars.Reston.Unisys.COM> dymm@cards.com (David Dymm) writes:
  13. >I would like to set up a restricted directory tree
  14. >on my Sun 4 system.  That is, certain users, when logging on,
  15. >would be placed into accounts that would be located in a
  16. >directory tree that would not have access to the rest of
  17. >the system directory structure. ...
  18.  
  19. The way my college did this was to create the restricted users
  20. in the 'peon' group-id.
  21. >All restricted directories were owned by group peon but with NO permissions.
  22. Correction: no GROUP permissions
  23.  
  24. That way, owner and all other have access but NOT peon.
  25. Although this is contradictory to the intent of permission GRANTING
  26. vs. permission denial, it works.
  27.  
  28. ex: /bin2 had commands that were not for peon use (moved over from /bin)
  29. dr-x---r-x   2 bin      peon         1664 Aug 26 16:14 /bin2
  30.  
  31. Permission checking uses the logic
  32.     if (effective UID == file UID)
  33.         if (file's owner permissions allows access)
  34.             ok
  35.         else
  36.             fail
  37.     if (effective GID == file GID)
  38.         if (file's group permissions allows access)
  39.             ok
  40.         else
  41.             fail
  42.     if (file's other permissions allows access)
  43.         ok
  44.     else
  45.         fail
  46.  
  47. This means that denying group access stops the peons cold, even though
  48. 'other' allows access.
  49. Had the logic been to 'or' all the lower permissions, then access
  50. denial would not be possible.
  51. But Unix says "if you're the owner, only the owner's permissions apply
  52. to you, even though others may have greater access priviledges".
  53.  
  54. As already mentioned an other postings, using the restricted shell also helps.
  55. I'm not sure if it was fixed, but there was a bug in how the shell
  56. determined if it was restricted or not.
  57. The old code checked for an 'r' in argv[0].  Anywhere in argv[0].
  58. This bit me when a login for 'smart' (a teaching program) used
  59. a C program that used 'system' to do something.
  60. The subshell inherited the argv[0] of 'smart' and since it contained
  61. an 'r', it went into restricted shell mode.
  62. The workaround was to alter argv[0] to something without any 'r'.
  63.  
  64. Set root is tricky becuase you need hard links for all things in /dev,
  65. /tmp and other things that are below the new root.
  66.  
  67. - Jeffrey Jonas
  68. -- 
  69. -- 
  70. Jeffrey Jonas
  71.  
  72. jeffj@synsys.uucp
  73.