system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (01/29/91)
In article <9101281715.AA16081@hwcae.cfsat.honeywell.com> rand@HWCAE.CFSAT.HONEYWELL.COM writes: >There is a subtle bug in Domain/OS with the Unix cp -r command and the >required ACL entries. It shows itself on directories that have >explicit owners and protections (ie. no (U) umask or (P) process >ownership). We too have had problems with ACLs and cp, but we mainly use pure BSD ACLs on everything outside of /sys, so things usually end up OK. I always check the new directory tree after 'cp -r' and rbak, and sometimes I have had to do recursive chacl's and chown's to fix ownerships (rbak does not restore BSD initial file/directory ACL's properly and a 'chacl -R -B' fixes them). >This was reported in APR 5B54C694. Unfortunetly HP/Apollo said "Use >/com/cpt." Well, how about people who don't load Aegis? I agree completely - "use Aegis" should never be offered by Apollo as a response, and certainly should not be accepted by a user. While I have Aegis loaded on our DN10000 due to other problems, I don't know how to do anything with it, and don't want to learn. None of our m68k nodes even have Aegis loaded. We bought Apollo because they said they had BSD UNIX, and that it worked WITHOUT needing proprietary OSs. >The official line from HP/Apollo is that they won't fix it. Here is the >text of the HP/Apollo response to the APR: > >> <deleted with barely restrained comments> > >I must say that once we persuaded HP/Apollo that this actually >happens, they were pretty good about it. All of the people we talked >to at the Hot Line agreed that this is a bug. (In fact the person >who told us that there was an APR already written, asked us not to >kill the messenger.) I believe that it is somebody in Engineering that >said it won't be fixed. I can't count how many APR's I have that "won't be fixed", or that the product is "working within specification" even though it doesn't work properly (who makes up the "specifications" and what good are they if the product still doesn't function reasonably yet meets specs?). >(On another note, it was very difficult to persuade HP/Apollo that we >were not some dumb idiots. With the first person, it took 30 minutes >on the phone working through an example. Then somebody else got it, >and the response was "Operator error." Even though we had already >demonstrated the bug to another person there. Days latter, and after a >fax of a transcript, the second person agreeded with us too.) I've seen lots of this too, but not nearly as much recently as when SR10 first came out. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
rees@pisa.ifs.umich.edu (Jim Rees) (01/30/91)
In article <1991Jan28.190504.28488@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:
I agree completely - "use Aegis" should never be offered by Apollo
as a response, and certainly should not be accepted by a user.
Hey, wait a minute -- this problem resulted precisely because the user DID
use Aegis, and set a non-bsd acl on a directory. Now he's complaining
because he can't deal with that directory without using Aegis tools.
If you stick with bsd acls, you won't have this problem. I think the bsd
tools that deal with acls (lsacl, chacl, and friends) were meant to give the
bsd user a minimum ability to deal with the acls he is likely to encounter
while using his node. That's what I use them for, and they work fine for
that purpose. It doesn't surprise me that when you start setting your own
Aegis (non-bsd) acls, those tools aren't sufficient any more.system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (01/31/91)
In article <4f80225e.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >In article <1991Jan28.190504.28488@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: > > I agree completely - "use Aegis" should never be offered by Apollo > as a response, and certainly should not be accepted by a user. > >Hey, wait a minute -- this problem resulted precisely because the user DID >use Aegis, and set a non-bsd acl on a directory. Not necessarily - you can (and we do) set any ACL's on any object using just tools provided in BSD environments (chacl to be specific). The problem was that cp does not copy some ACL's properly. If Apollo is going to modify the UNIX protection scheme, they must then ensure that all the UNIX tools that manipulate them also work properly. I agree that if you stick with standard BSD ACL's, the problems are minimized. I would love to be able to ignore ACL's completely, but if you set BSD ACL's on /sys, I doubt that your node would boot properly, and many NCS/Aegis-related things won't work any more (I did this once by accident by doing 'chacl -R -B' when I was in /). -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) (02/05/91)
In article <1991Jan28.190504.28488@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >I can't count how many APR's I have that "won't be fixed", or that the >product is "working within specification" even though it doesn't work >properly (who makes up the "specifications" and what good are they if >the product still doesn't function reasonably yet meets specs?). Sounds all too familiar. When I complained that lint breaks on ANSI-C code and they should correct that, they answered that they use the code they got from ATT. And that therefore, it's not their fault. They don't have enough time to fix it, I should use the C compiler. I guess I should send in an APR complaining that the C compiler is not a fully functional lint replacement, as was implied by their response. ;-) bye, mike Michael K. Gschwind, Institute for VLSI-Design, Vienna University of Technology mike@vlsivie.tuwien.ac.at 1-2-3-4 kick the lawsuits out the door mike@vlsivie.uucp 5-6-7-8 innovate don't litigate e182202@awituw01.bitnet 9-A-B-C interfaces should be free Voice: (++43).1.58801 8144 D-E-F-O look and feel has got to go! Fax: (++43).1.569697