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.