chmod and ACLs (was Re: Standards Update, IEEE 1003.6: Security Extensions)

[Badger BA 64810]

From: bbadger at x102c.harris-atd.com (Badger BA 64810)

In article <467 at longway.TIC.COM> std-unix at uunet.uu.net writes:
>From: Jeffrey S. Haemer <jsh at usenix.org>
[...]
>Ana Maria de Alvare <anamaria at lll-lcc.llnl.gov> reports on the October
>16-20, 1989 meeting in Brussels, Belgium:
[...]
>Discretionary Access Control (DAC)
>
[...]
>It was noted that the current proposed Access Control List (ACL) might
>not be fully compatible with the current behavior of a 'chmod' call.
  It definitely isn't!
>ACL, a 'chmod' will provide the old behavior for the "owner" and
>"other" fields, but the "group" field permissions as set by 'chmod'
>and shown by 'stat', wouldn't represent the actual access permissions
>of the group associated with that file; instead, it's a summary of all
>access permissions included under the ACL list for group entries.  In
>other words, it would represent the maximum permissions allowed to the
>group entries included in the ACL list.
Unfortunately, under this scheme it is impossible for ``old style'' 
programs to get the access checks they want.  For example,
 chmod(rw-r--r--) with an ACL for JOE:rw present results in rw-rw-r--,
granting the entire file-group write access!  This is not what was
wanted.  
>
>Some participants argued that 'chmod' should be replaced by other
>system calls in a system conforming to 1003.6.  In other words, if
>your system were to conform to 1003.6 the behavior of chmod would be
>unspecified and unpredictable.
>
>I disagree.  Although defining the behavior of 'chmod' might restrict
>some implementations of ACLs, having a well-defined chmod behavior
>will provide backward compatibility and ease porting old programs to
>1003.6-conformant systems.  Otherwise old programs will have to be
>ported to platforms with system-dependent representations of 'chmod'
>and 'stat' information.
[...]

I'm with you on this.  The Harris Compartmented Mode Workstation
provides the file with a ``compatibility flag'' which indicates
whether the last DAC operation on the file was ``old-unix''
(open,create, or chmod) or ACL-smart (sec_open, sec_create, or
set_acl).  If the last operation was not ACL-smart, all ACL entries
which may be present (from previous set_acl() or through default ACLs)
are masked by the ``others'' permission bits on the file.  (I've seen
the ``rationale'' for masking with the ``group'' permissions, but it
just doesn't reflect what someone who is setting rw-rw-r-- is trying
to do!)

The ACLs are still present, and can be made effective by doing a set_acl
on the file.  This sheme provides a compatibilty which only restricts 
those in the ``others'' category, and respects the choice of chmod in the
``user'' and ``group'' categories.

(There are other features, such as exclusionary, control, and default 
attributes, but that's another topic.   BTW, Addamax corp. is 
our teammate and handles the marketing, so don't send me any inquiries,
please.)
    -----	-	-	-	-	-	-	-	----
Bernard A. Badger Jr.	407/984-6385          |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: bbadger%x102c at trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.

Volume-Number: Volume 17, Number 100