Path: utzoo!utgpu!watmath!clyde!att!rutgers!gatech!mcnc!xanth!ames!pasteur!ucbvax!NUSVM.BITNET!GBOPOLY1
From: GBOPOLY1@NUSVM.BITNET (fclim)
Newsgroups: comp.sys.apollo
Subject: re: acls probs with domain/ix
Message-ID: <8812031046.AA00652@umix.cc.umich.edu>
Date: 3 Dec 88 10:48:20 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 69
X-Unparsable-Date: Sat, 3 Dec 1988 18:30:04 SST


     blake coverett writes about the mis-mesh between aegis /com/acl
and domain/ix /bin/chmod.

     after chmod-ing test to 700, he gets % -d- in the acl. then
he su to *root* and rm test.

     if he had done an ls -l on test, he would get -rwx------.  and i
suppose that if he had done an ls -l on the directory containing test,
he would get drwxr-xr-x or something similar.   ie
% ls -ld .
drwxr-xr-x  * coverett   *  *  .

     thus, root has no write permission on the parent directory.
but root is root.  unix allows root to do anything.  since root
has no write permission on the holding directory, unix seeks an answer
to overwrite the 700 permission on test.  if that answer is 'y', unix
will delete the file, irregardless of the write permission on test.

     if blake has switch user to some account other than root, he'll
find that he *can't* rm test.

     i suppose that blake is confused with the fact that a 'd' in the
acl of a file means permission to rm or /com/dlf.  the man page on
/com/edacl says that a file needs 'd' on its acl and a 'e' on the acl
of its parent directory.  (unix only requires a 'w' on the permission
of the parent directory; unix will ignore the permission of the file
itself).

      /* end of help */
      /*  *flame* on  */
     what i don't understand (and don't like) is why apollo.com has
introduce such complications into file system permissions.  i like
the idea of an access control *list* whereby i may be able to give
permission to a narrower group of users irregardless of which group
the sys_admin has put me into.
     i don't like the 'pgnals' options.  if i allow user foo to read
a file, and he wants user bar to read it as well, he doesn't need
the 'p' option; foo can just cp or mail the file over to bar.  if
foo is ethical, he would inform me before mailing the file to bar.
in that case, i would give bar the permission to read as well instead
of foo mailing it to bar.  if foo, bar and i are in a project group,
i would give both of them the 'r' and 'w' (?) rights at the onset.
     i don't understand the 'g' acl right; it just introduce
complications to understanding the concept of acl.  in the polytechnic,
we have never remove the 'n' right; all nodes has access to all objects
on the file system.  furthermore, i believe the network licencing scheme
would cover this.  the 'als' rights are covered by unix more simpler:
'a' and 'l' are similar to unix's  write permission in the parent dir;
's' being similar to 'x' in the parent dir under unix.
     i accept the 'c' and 'e' rights, although i think the 'c' permission
should just be restricted to deleting links; i can't see why my project
members want to rename the file that i create.  (they may edit the file
and use dsee to inform of the change).  but i wouldn't allow any other
random users to rename my files.  (they may read and/or execute).

     if apollo.com removes all the rights that i have mentioned, then
their manuals would be simpler and more people will be less shy of acls.

     /*  *flame* off  */
#include "std-disclaimer.h"
static char *str="the above opinions and misconceptions are mine and mine 
alone";

fclim          --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.