GBOPOLY1@NUSVM.BITNET (fclim) (12/12/88)
oops! i made a boo-boo when i replied to blake coverett's mail on acls problems under domain/ix -- i didn't see that blake had su to user. anyway, because the acls on the parent directory of test are > % /com/acl . > Acl for .: > blake.%.%.% pgndcalrse > %.backup.%.% -------rse > %.sys_admin.%.% pgndcalrse > %.%.%.% --------se any random user has the (e)xpunge right. after a chmod, the system add a "spurious" (d)elete right to test. thus, a random user has both e and d rights, allowing him to delete test. remember, unix's permission modes are stored in aegis acl rights. > % ls -ld . > drwxr-x--x 1 blake 4096 Dec 6 02:02 . > % chmod 700 test [text deleted] > % ls -l test > -rwx------ 1 blake 37 Dec 6 23:56 test it doesn't matter what domain/ix says about the permission on test and its parent. here, any unix user would tell you that a random user has no permission to delete test. but the actual permission on test and its parent are still that of the aegis acls which allows any user to delete test. if blake were to take away the expunge rights on the parent of test, he will find that his problem will be solved. [i didn't get the same problem on my system because on my system, the acl on . is % -rs-.] ==================================================== aegis acls and domain/ix permission modes are mis-meshed. this is because aegis acls has, as what blake has wrote, a finer degree of control. the aegis acl rights of c, l, a, and e on a directory are represented all by one unix mode, w. furthermore, unix doesn't has anything similar to aegis d right on a file. what i think is broken is the incorrect mapping of aegis acl rights to unix permission modes. the % -se- right and %.foo -se- right should have been mapped to drwxrwxrwx. furthermore, since there's no way to translate test's % -d- rights, domain/ix shouldn't add the spurious d whenever one uses chmod. >As close as I can figure, the query about overriding does not come >from unix, because when logged on as root it does not occur regardless >of what you delete. no, the query about overriding comes from unix; in fact from /bin/rm: >B$ rm //cmr_1/users/etud/blake/test >rm: override protection 700 for //cmr_1/users/etud/blake/test? y what is (?) broken is that /bin/rm doesn't do a fstat(2) or stat(2), but calls some undocumented aegis system routine like acl_$getentry() or something similar. so /bin/rm doesn't know or doesn't care that the mode on the parent is rwx------. ==================================================== later, blake writes of my replies: [mine] >> 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. [his] >In defense of ACL's, like anything else, there is additional complexity involve >in providing better functionality. Apollo's acls allow a much finer degree >of control over who can access which object and how they may be accessed than >unix's permissions. The idea that the 'additional' rights which aegis provides >confusing users is completely subjective. i believe i had qualified myself as saying that i feel an access control list is useful to narrow the group of users who can access my files irregardless of what group the sys_admin has put me in. what i don't like are the 'additional' rights introduced in aegis. under unix, when i said 'thou shall not create anything under this directory of mine', i mean any objects of any kind; may they be files, directories, or links. at the same time, i forbid thou to delete any objects i have create there; may they be files, directories, or links. nor do i allow thou to rename the objects there. just do a look (ls), read (cp) or run the programs i have there. do not come, see and conquer. so why have those additional rights of c, l, a, and e, when a simple w suffices? furthermore, i don't understand why any user would want to take the 'p' right away from himself and give it to others. a simple /etc/chown is much better. if i am in a project group, i will still retain the 'p' right on the files that i create. but, i will not give 'p' and 'g' rights to the members of my group; although i may give them both 'r' and 'w' rights. i don't forsee any reason why members would want to (g)rant a subset of the acls to persons outside of the project group and to (p)rotect (or unprotect) the files that i've initiated. any granting and protecting should be done by me, the author. >It is based on the assumption that >the users already understand the unix permissions and see these as an add on. >At our (site), the majority of the users had never been exposed to a vanilla >unix system before and the aegis acls where the first protection they used >on the apollos. In our case, the concepts behind standard unix permissions >have caused much more confusion than acls. maybe blake should elaborate on this. do the majority of the users understand everything about aegis acls or just enough to get by from day to day? i believe it will take less time and effort to learn unix permissions than aegis p, g, d, c, a, l, s, and e rights and about the concept of initial acls. under aegis, every subordinate objects get their acl rights from the parent whereas under unix, the subordinate obejcts get their permission modes from the grandfather -- the global umask value. anyway, apollo.com has taken away the g, n, d, c, a, l, s, and e rights in sr10. i have not seen the sr10 manuals but i suspect the chapter on acl rights would be thinner than what i am reading now. /************************************************************ *** *** these comments are my opinions and misconceptions *** and mine alone. *** ****/ /* *flame* off */ :-) Have a Merry X'mas and a Happy New Year. :-) fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.
achille@cernvax.UUCP (achille) (12/13/88)
All the problems being described on this list on ACLs and Unix protections can be resumed in a very simple way: If the directory is created via Unix, you can safely use chmod (i.e.: mkdir will remove the e(xpunge) right from %), if you create the directory with Aegis (crd) you MUST remove the e right before you start using Unix chmod on files created under it. DON'T mix up Aegis ACLs with Unix chmod !!! I got no problem since I use this simple rule. Now the trouble is that the Domain/IX install uses Aegis to create directories !!! At least it was so at sr9.2 when I last checked, so protections on Unix dirs are not completely OK. Hope this helps, Achille Petrilli, Cray and PWS Operations
thompson@cpsc.ucalgary.ca (Bruce Thompson) (12/16/88)
In article <8812100838.AA25757@umix.cc.umich.edu>, GBOPOLY1@NUSVM.BITNET (fclim) writes: > > furthermore, i don't understand why any user would want to take the > 'p' right away from himself and give it to others. a simple /etc/chown > is much better. > if i am in a project group, i will still retain the 'p' right on > the files that i create. but, i will not give 'p' and 'g' rights > to the members of my group; although i may give them both 'r' and > 'w' rights. i don't forsee any reason why members would want to > (g)rant a subset of the acls to persons outside of the project group > and to (p)rotect (or unprotect) the files that i've initiated. > any granting and protecting should be done by me, the author. I think that a valid point is being missed here. It seems to me that a project leader/administrator would find the (P) and (G) rights extremely useful. This would allow him/her to take full responsibility for the security of the project's tree, granting project members appropriate rights, etc. This would tend to support a decentralized system admin. approach. The overall (root) system administrators could spend their time dealing with global issues, while the individual project administrators deal with issues concerning the particular project. As well, a project administrator has the freedom to create shared directory areas, where the issue of who 'owns' the directory, and/or the files and sub-directories, is moot. Take a look some time at the project administration/system administration setup in use on MULTICS systems. It seems to me that the ACLs on Apollos were intended to allow this sort of admin. organization. The key point though is that there is nothing which implies that this sort of approach MUST be used. Admittedly, this whole issue seems to have evolved out of a legitimate complaint with regards to the UNIX to AEGIS security mappings, I don't think the problem resides in the additional functionality which ACLs provide. Cheers, Bruce Thompson ------------------------------------------------------------------------------ Bruce Thompson | "Never get into an argument with a University of Calgary, | fool. People may not be able to Computer Science Department | tell the difference" - ???? (403)220-3538 or (403)220-5017 (office) | | "Don't look at me, I only say ...!alberta!calgary!vaxb!thompson | them."