Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!ukma!nrl-cmf!ames!pasteur!ucbvax!CMR001.BITNET!Blake_Coverett From: Blake_Coverett@CMR001.BITNET (Blake Coverett) Newsgroups: comp.sys.apollo Subject: (none) Message-ID: <8812070724.AA01384@umix.cc.umich.edu> Date: 7 Dec 88 07:05:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 122 Subject: Re: flames on aegis acls (was re: acls probs with domain/ix) There seems to have been some misinterpretation of the problem I documented in my last message, so here comes a rehash: -----------------------cut here---------------------- Bienvenue dans l'environnement UNIX bsd4.2. % /com/acl test Acl for test: blake.%.%.% pgndwrx %.backup.%.% -----r- %.sys_admin.%.% pgndwrx %.%.%.% ------- % /com/acl . Acl for .: blake.%.%.% pgndcalrse %.backup.%.% -------rse %.sys_admin.%.% pgndcalrse %.%.%.% --------se % ls -l test -rwxrwx--- 1 blake 37 Dec 5 01:16 test % ls -ld . drwxr-x--x 1 blake 4096 Dec 6 02:02 . % chmod 700 test % /com/acl test Acl for test: blake.%.%.% p-ndwrx %.sys_admin.%.% ---d--- %.backup.%.% -----r- %.%.%.% ---d--- % ls -l test -rwx------ 1 blake 37 Dec 6 23:56 test % su user Password: B$ rm //cmr_1/users/etud/blake/test rm: override protection 700 for //cmr_1/users/etud/blake/test? y B$ *** EOF *** % ls test test not found % -----------------------end here---------------------- fclim replied to my previous message: > after chmod-ing test to 700, he gets % -d- in the acl. then >he su to *root* and rm test.> if blake has switch user to some account other than root, he'll >find that he *can't* rm test. I didn't su to root. I su'ed to user.none.none, this is the apollo equivalent of guest on most unix systems, as such it has no special rights, and often has less access the 'normal' users. 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. It seems that is caused by that spurious -d- in the acl. ====================================================================== In response to the flames in the same message from fclim: > 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. No he doesn't need the 'p' option, that is what the 'g' priviledge is for. > 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. In defense of ACL's, like anything else, there is additional complexity involved 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. It is based on the assumption that the users already understand the unix permissions and see these as an add on. At our sight, 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. >finally, i believe that the unix's set-uid bit should be replaced by >aegis concept of a sub-system as this is much better in terms of >security besides other benefits. This is an interesting topic, I have used both techniques recently and find that they are complementary. Personally I would miss either if they were to vanish (mostly because I would have to do some fast patching to parts of our system to keep it working :-} ) Does anyone else have any comments on this? CP6 : Blake Coverett @CMR ____ BITNET: / ) / / MaBell: (514) 346 2131 ext. 3785 _____ /____/ / __ ) /__ __ 4 sqn CMR, St-Jean PQ. JOJ 1R0 / ) / / / /\ /__) "The question is not whether the OS or the /____/ / (__( / \ (__ hardware is any good, but rather whether you can make it do what needs to be done."