home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0107.txt < prev    next >
Encoding:
Text File  |  1990-01-06  |  10.0 KB  |  228 lines
  1.  
  2. In article <473@longway.TIC.COM>, Bernard Badger Jr. of Harris GISD,
  3. Melbourne, FL raised some comments on chmod and ACLs.  As active
  4. members of the 1003.6 group working on Access Control Lists, we
  5. would like to explain the current PROPOSED 'chmod' behavior when
  6. used on files that contains ACLs.
  7. (Don't worry, it only seems complicated! ;-)
  8.  
  9. Ana Maria De Alvare' and Mike Ressler
  10. =======
  11.  
  12.  
  13. 1.  File Group Class Permission Bits
  14.  
  15. 1.1  The Original Scheme
  16.  
  17. The file permission bits cannot possibly reflect all the
  18. information that can be contained in an ACL.  However, it is
  19. considered desirable that "long directory listings", i.e., "ls
  20. -l", still reflect a reasonable amount of information regarding
  21. the access rights of files.
  22.  
  23. The approach taken was a compromise.
  24.  
  25.    The file owner class permission bits will reflect the
  26.    permissions associated with the USER_OBJ entry of the ACL.
  27.    The file other class permissions bits will reflect the
  28.    OTHER_OBJ entry of the ACL.  The file group class
  29.    permission bits will reflect the union of the permissions
  30.    associated with the GROUP_OBJ and all named USER and GROUP
  31.    entries in the ACL.
  32.  
  33. This method will allow the file permission bits to reflect the
  34. maximum permission that might be granted in the ACL.  Thus
  35. inspection of these bits will not show the exact access rights of
  36. a user but it will show the maximum that the user might have.
  37. For example:
  38.  
  39.                     mpr     posix   rwxr--r--
  40.  
  41. indicates exactly what access rights are available to user "mpr"
  42. and also indicates that no other user can "write" the file.
  43.  
  44. The question of why the file other class is not used instead of
  45. the file group class has been raised several times.  One fallacy
  46. has been that if the ACL were associated with the file other
  47. class, it could be determined exactly what the access for the
  48. owner and owning group of the file would be.  The permission for
  49. the owner would be known, as is the case when the file group
  50. class is used, however the permissions for the group could not be
  51. determined, because a match may occur for a specific user entry
  52. in the ACL (specific users entries are checked before any group
  53. entries).
  54.  
  55. 1.2  Complications due to chmod
  56.  
  57. Since compatibility with P1003.1 is critical, a chmod function
  58. must change the access rights as currently defined by standard
  59. practice and P1003.1.
  60.  
  61.    Therefore, the effect of the chmod will be to change the
  62.    USER_OBJ entry of the ACL and the file owner class
  63.    permission bits to the permissions stated in the argument
  64.    of the chmod.  The OTHER_OBJ entry of the ACL and the file
  65.    other class permission bits will also change to the
  66.    permission bits stated in the argument of the chmod.  The
  67.    file group class permission bits will change to the
  68.    permissions stated in the argument of the chmod.  The
  69.    GROUP_OBJ entry of the ACL and the named USER and GROUP
  70.    entries will not be effected by the chmod.
  71.  
  72. Since the file group permission bits are used as a mask in the
  73. access algorithm, the chmod can be effectively used to limit
  74. permissions on a file without inadvertently trashing the contents
  75. of the ACL.  (The use of the chmod to extend the access rights of
  76. the GROUP_OBJ of the file will not always work as expected.  An
  77. alternative not discussed by the DAC group would be to also
  78. change the GROUP_OBJ ACL entry as a result of the chmod.)
  79.  
  80. As was just shown, the chmod function can cause the file group
  81. permission bits to no longer reflect the maximum of the
  82. permissions associated with the GROUP_OBJ and all named USER and
  83. GROUP entries in the ACL.  However, due to its use as a mask in
  84. the access algorithm, the file group permission bits will
  85. continue to reflect the maximum permissions granted to non-
  86. USER_OBJ users.
  87.  
  88. 1.3  Complications due to creat
  89.  
  90. When a file is created using creat, the file permission bits and
  91. associated ACL are created using both the file creation mask
  92. specified as an argument to creat and the default ACL, if
  93. present, in the containing directory.  (The decision to place
  94. default ACLs in the containing directory is discussed in the
  95. "Defaults" section.)  The file permission bits are created as
  96. follows.
  97.  
  98.    The file owner permission bits are the intersection of the
  99.    USER_OBJ specified in the default ACL and the file owner
  100.    permission bits specified in the file creation mask
  101.    argument of creat.  Similarly, the file other permission
  102.    bits are the intersection of the of the OTHER_OBJ specified
  103.    in the default ACL and the file other permission bits
  104.    specified in the file creation mask argument of creat.  The
  105.    file group permission bits are the intersection of the file
  106.    group permission bits specified in the file creation mask
  107.    argument of creat and the file group permission bits that
  108.    would have been calculated from the GROUP_OBJ and named
  109.    USER and GROUP entries in the default ACL.
  110.  
  111.    The resulting associated ACL will contain a USER_OBJ and
  112.    OTHER_OBJ entry that reflect the file permission bits
  113.    described above.  The GROUP_OBJ entry and named USER and
  114.    GROUP entries will be copied from the default ACL without
  115.    modification.
  116.  
  117. The net effect of this process will be access control rights that
  118. reflect the minimum of the creat mode creation mask and the
  119. default ACL.  This seems reasonable as it provides both the owner
  120. of the directory and the author of the software a say in
  121. determining the access rights of the resulting file.
  122.  
  123. 1.4  Undoing the Complication
  124.  
  125. As shown above, due to the interaction of existing DAC
  126. mechanisms, namely the creat and chmod functions with the ACL
  127. mechanisms, the ACL entries may not truly represent the access
  128. control decisions that will be made.  This condition will exist
  129. whenever the file group permission bits are not equal to the
  130. union of the GROUP_OBJ and the named USER and GROUP entries of
  131. the ACL.  This condition can only further restrict the access
  132. control protections specified in the ACL since the file group
  133. permission bits are used as a mask.
  134.  
  135. However, there must be a mechanism for reinstating the access
  136. control protections that are stated in the ACL.
  137.  
  138. 1.5  Recalculating the File Group Permission Bits
  139.  
  140. Several options were considered for recalculating the file group
  141. permission bits.
  142.  
  143. 1.5.1  Automatic_Recalculation
  144.  
  145. The initial proposal was to recalculate the file group permission
  146. bits whenever a new ACL entry is added.  The following example
  147. illustrates a problem with this approach.
  148.  
  149.    Consider a file created with a file creation mask of 0 in a
  150.    directory that contained a fully populated default ACL.
  151.    This file will have file group permission bits of 0, i.e.,
  152.    --- yet may have named USER or GROUP entries specifically
  153.    granting permissions.  (These entries will be effectively
  154.    ignored during access checking because of the masking
  155.    effect of the 0 file group permission bits.)  If the file
  156.    group permission bits are automatically recalculated
  157.    whenever a new ACL entry is added, the result of adding a
  158.    USER entry specifically denying a user access will be to
  159.    effectively grant access to the previously masked ACL
  160.    entries.
  161.  
  162. It seems counter-intuitive at best to have the net effect of
  163. adding an entry that denies a user access be the granting of
  164. access to other users.  However, there does not exist a technique
  165. to allow for the application of a single entry in an ACL and the
  166. exclusion of others.
  167.  
  168. 1.5.2  Other_Alternatives
  169.  
  170. Other proposed alternatives include providing a mechanism in the
  171. "set_ACL" function to specifically request recalculation.  A
  172. problem with this alternative is that it is not clear why one
  173. would ever add an entry to an ACL if it wasn't the intent to have
  174. it affect the access decision.  It isn't possible to have one new
  175. named USER or GROUP entry be guaranteed effective in the access
  176. algorithm without recalculating the file group permission bits
  177. based on all entries.
  178.  
  179. 1.6  Relationship of ACL and file permission bits
  180.  
  181. The file group class may be viewed as a mechanism for
  182. implementing ACLs in a POSIX-conforming way that avoids conflicts
  183. about alternate vs additional mechanisms.  ACL entries that are
  184. not of the type USER_OBJ or OTHER_OBJ are considered to specify
  185. additional members of the file group class, as permitted by the
  186. definition of the file group class.
  187.  
  188. For an object without additional file group class members (i.e.
  189. ACL entries), the file group class permission bits represent the
  190. exact and only permissions of the entire file group class. When
  191. an object has an extended ACL, the file group permission bits
  192. represent the maximum permissions of the entire file group class.
  193. Some members of the file group class permission bits (GROUP_OBJ
  194. or additional ACL entries) may have fewer or more permissions
  195. than are represented in the file group class permission bits
  196. proper. However, permissions granted to a member of the file
  197. group class will never be more than the permissions expressed in
  198. the file group class (i.e. the file group permission bits act as
  199. a 'mask' over the file group class entries).
  200.  
  201. When an ACL is placed on an object that previously had none, the
  202. implementation must ensure that the previous permissions of the
  203. GROUP_OBJ entry are preserved, unless they are specifically
  204. changed in the ACL being set.
  205.  
  206. We note that the use of chmod on an object that has an ACL is a
  207. use of an old mechanism in a new environment. There is no totally
  208. satisfactory way to specify the resultant behavior. We believe we
  209. should endeavor to support the intent of the chmod operation even
  210. at the expense of losing the ACL flexibility and specificity.
  211. Therefore a call to chmod must set the file group permission
  212. bits. However, the chmod operation should not set the permission
  213. bits of the GROUP_OBJ entry itself. This decision keeps the
  214. following case from granting more access to the GROUP_OBJ group:
  215.  
  216.    group_obj permission bits = r--; file group class = rwx
  217.    common programming sequence:
  218.         permbits := stat(obj)   gets file group class bits of rwx
  219.         chmod(obj,0)            temporarily disable access
  220.         chmod(obj,permbits)     'restore' old state; don't want
  221.                                 group_obj to become rwx instead
  222.                                 of r--.
  223.  
  224.  
  225. Volume-Number: Volume 17, Number 117
  226.  
  227.  
  228.