jimr@maths.su.oz.au (Jim Richardson) (06/07/90)
In article <2803@syma.sussex.ac.uk>, andrewn@syma.sussex.ac.uk (Andrew D Nimmo) writes: >Could someone please post a list of patches to this group -- >I am having no luck through any other channels. I haven't seen any other responses yet, so I'll bite. Here is the list of patches on the March 1990 SR10.2 patch tape (a small extract of a file, copyright Hewlett-Packard Company 1990, which I reproduce here for the purpose of fair comment :-) : Patch Kit M68K_9003 Patch # Description Blocks Date Patch_m0122 /sau7,8,9 domain_os 2457 9003 Patch_m0121 security patch 118 9003 Patch_m0120 /lib/streams 568 9003 Patch_m0119 /lib/pmlib 389 9003 Patch_m0118 /lib/kslib 133 9003 Patch_m0117 /lib/ftnlib 125 9003 Patch_m0116 /lib/tfp 131 9003 Patch_m0115 /lib/kslib Replaced by Patch m0118 (9003) Patch_m0114 /sau7,8,9 ring.dex 598 9002 Patch_m0113 /sau7,8,9 domain_os Replaced by Patch m0122 (9003) Patch_m0112 /lib/gprlib 954 9002 Patch_m0111 /lib/rgylib 148 9002 Patch_m0110 /lib/dseelib (9.7) 1892 9002 Patch_m0109 /lib/dseelib 2049 9002 Patch_m0108 /etc/routed 41 9001 Patch_m0107 /etc/ftpd and ftp 418 9001 Patch_m0106 DPCE fixes 1385 9001 Patch_m0105 DPCC fixes 1541 9001 Patch_m0104 /sau7/domain_os 792 9001 Patch_m0103 SNA 3770 fixes 5 9001 Patch_m0102 /sys/sna_3770/rje 157 9001 Patch_m0101 /sau7/ctape7b.dex 80 9001 Has anyone got a later tape? Note that m0121 is a vital security patch which no multi-user Apollo site should be without ... I would have been much happier if we'd received the tape automatically *before* we stumbled on the security hole which m0121 addresses, instead of as an informal response to an APR. I am not going to post any details of the hole (and I beg other people not to do so either): believe me, it's a nasty one. On another matter I had some hopes that patch m0111 would fix the extraordinary bug shown below, but it just perturbed it slightly. % cat > pwbug.c << EOF #include <pwd.h> #include <sys/wait.h> main( int argc, char **argv ) { register struct passwd *pw; extern struct passwd * getpwnam(); int pid; char * NullEnv = (char *)0; union wait status; if ( (pw = getpwnam("root")) != (struct passwd *)0 ) printf( "getpwnam(root) worked: root has uid %d\n", pw->pw_uid ); else printf( "getpwnam(root) failed\n" ); if( argc > 1 ) switch( pid = fork() ) { case 0: execve( argv[1], argv+1, &NullEnv ); /* does not return */ perror( "execve failed: " ); _exit( 1 ); default: wait( status ); } } EOF % cc pwbug.c -o pwbug % pwbug pwbug # see below getpwnam(root) worked: root has uid 0 getpwnam(root) worked: root has uid 0 % pwbug /bin/ps u # dies with no message ... getpwnam(root) worked: root has uid 0 USER PID SZ RSS TTY STAT TIME COMMAND % tb -last # ... but tb explains what happened ... Process 6377 (parent 6376, group 6376) Time 90/06/07.17:15(AEST) Program /bsd4.3/bin/ps Status 03080003: heap corruption detected; block header incorrect \ (process manager/basic heap storage manager) In routine "pm_$proc_release" line 2105 Called from "pgm_$invoke_uid_pn" line 1160 The above is after the patch. At least it has fixed the "pwbug pwbug" variant of the problem, which before the patch did this: % pwbug pwbug getpwnam(root) worked: root has uid 0 getpwnam(root) failed The bug did not exist at 10.1. On some nodes 10.2 you didn't get failure with one exec, but (before the patch) % pwbug pwbug pwbug pwbug pwbug pwbug always seemed to fail. There's nothing like a nice diagonal counter-example! I APRed this (ID 6E3C480C) on 19 March, but have had no response. On the whole, APR response in Australia is slow to non-existent: is this so everywhere else too? -- Jim Richardson Department of Pure Mathematics, University of Sydney, NSW 2006, Australia Internet: jimr@maths.su.oz.au ACSNET: jimr@maths.su.oz FAX: +61 2 692 4534 "When she was dark she was very very dark, but when she was light she was lighter than air." -- J. Crowley
awhitton@bcara132.bnr.ca (Alan Whitton) (06/07/90)
In article <1990Jun7.073655.20620@metro.ucc.su.OZ.AU>, jimr@maths.su.oz.au (Jim Richardson) writes: > In article <2803@syma.sussex.ac.uk>, andrewn@syma.sussex.ac.uk (Andrew D Nimmo) > writes: > >Could someone please post a list of patches to this group -- > >I am having no luck through any other channels. > > I haven't seen any other responses yet, so I'll bite. Here is the list of > patches on the March 1990 SR10.2 patch tape (a small extract of a file, > copyright Hewlett-Packard Company 1990, which I reproduce here for the > purpose of fair comment :-) : > Has anyone got a later tape? > Yup and here it is: 1. Patch Kit Contents.......................................... 1-1 1.1 Patch m0149 ikon85.................................... 1-3 1.2 Patch m0147 Aegis Print Components.................... 1-4 1.3 Patch m0146 /lib/gmr3dlib............................. 1-6 1.4 Patch m0145 /lib/gprlib, /sys/mgrs/dtm_mk3............ 1-7 1.5 Patch m0144 /sau9/domain_os........................... 1-8 1.6 Patch m0143 /sau5,6,7,8 domain_os..................... 1-9 1.7 Patch m0142 /sys/vtserver............................. 1-11 1.8 Patch m0141 /com/wbak................................. 1-11 1.9 Patch m0140 /lib/clib................................. 1-11 1.10 Patch m0139 /lib/streams.............................. 1-12 1.11 Patch m0138 /sau3/domain_os........................... 1-12 1.12 Patch m0137 /sys/dm/dm................................ 1-13 1.13 Patch m0136 /lib/ftnlib............................... 1-14 1.14 Patch m0134 /sau7, 8 domain_os........................ 1-15 1.15 Patch m0131 /sau2-9/salvol, /etc/salvol............... 1-15 1.16 Patch m0130 /sys/mgrs/dds............................. 1-16 1.17 Patch m0129 /lib/syslib.881........................... 1-16 1.18 Patch m0128 /lib/spe_pio_lib.......................... 1-17 1.19 Patch m0127 /com/bmail................................ 1-17 1.20 Patch m0126 /sau9/self_test........................... 1-17 1.21 Patch m0124 /etc/invol, /sau9/invol................... 1-18 1.22 Patch m0122 /sau7,8,9 domain_os....................... 1-18 1.23 Patch m0121 /usr/apollo/bin/rbak...................... 1-18 1.24 Patch m0120 /lib/streams.............................. 1-19 1.25 Patch m0119 /lib/pmlib................................ 1-19 1.26 Patch m0118 /lib/kslib................................ 1-20 1.27 Patch m0117 /lib/ftnlib............................... 1-20 1.28 Patch m0116 /lib/tfp.................................. 1-20 1.29 Patch m0115 /lib/kslib................................ 1-21 1.30 Patch m0114 /sau7,8,9 ring.dex and ring.drvr.......... 1-21 1.31 Patch m0113 /sau7,8,9 domain_os....................... 1-22 1.32 Patch m0112 /lib/gprlib............................... 1-22 1.33 Patch m0111 /lib/rgylib............................... 1-22 1.34 Patch m0110 /lib/dseelib for SR9.7 Nodes.............. 1-22 1.35 Patch m0109 /lib/dseelib for SR10.1 and SR10.2 Nodes................................................. 1-23 1.36 Patch m0108 /etc/routed............................... 1-23 1.37 Patch m0107 ftpd and ftp.............................. 1-24 1.38 Patch m0106 DPCE Fixes................................ 1-24 1.39 Patch m0105 DPCC Fixes................................ 1-25 1.40 Patch m0104 /sau7/domain_os........................... 1-26 1.41 Patch m0103 SNA 3770 Fixes............................ 1-27 1.42 Patch m0102 /sys/sna_3770/rje......................... 1-28 1.43 Patch m0101 /sau7/ctape7b.dex......................... 1-28 Cheers, Alan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- BNR Ottawa Disclaimer: "This is only my opinion" BITNET: awhitton@bnr.ca OR UUCP: ...uunet!bnrgate!forum!awhitton
pha@CAEN.ENGIN.UMICH.EDU (Paul H. Anderson) (06/07/90)
On the subject of patch tapes: has anyone figured out how to get HP/Apollo to ship one each month automatically? These tapes are critical to the survival of a large net, yet it is a pain in the backside having to call them up and beg somebody to send one. Paul Anderson CAEN Systems Programmer University of Michigan
rees@dabo.ifs.umich.edu (Jim Rees) (06/08/90)
These lists are great. Now, does anyone have a list of what bugs they are supposed to fix? Also, I'd like to recommend psk5 to anyone who uses X. It's absolutely essential. It gives you a big performance boost. On the subject of APRs, I don't think your experience in Oz is any worse than ours. I usually get a snail-mail ack in a few weeks. I have yet to get an actual reply to any APR I have filed. After using Apollos since 1983, I filed my first APR on March 3 of this year and am still waiting for an answer. Just to be fair, I should point out that it was a pretty low priority (plot(1) command doesn't work).
awhitton@bcara132.bnr.ca (Alan Whitton) (06/08/90)
In article <1990Jun7.170336.19246@terminator.cc.umich.edu>, rees@dabo.ifs.umich.edu (Jim Rees) writes: > On the subject of APRs, I don't think your experience in Oz is any worse > than ours. I usually get a snail-mail ack in a few weeks. I have yet to > get an actual reply to any APR I have filed. After using Apollos since > 1983, I filed my first APR on March 3 of this year and am still waiting for > an answer. Just to be fair, I should point out that it was a pretty low > priority (plot(1) command doesn't work). To be fair to Apollo , their APR system is being phased into the HP stars (?) system and things are kind of "willy nilly" with the submissions, e.g. I phoned a call into the Apollo hot line and got back a normal APR number from them ( APR DDDDD, or the like), but I submitted a second APR and got back a MUCH LARGER number. I guess this is another transition problem from Apollo to HP. Cheers, Alan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- BNR Ottawa Disclaimer: "This is only my opinion" BITNET: awhitton@bnr.ca OR UUCP: ...uunet!bnrgate!forum!awhitton
dr@stl.stc.co.uk (David Rutter) (06/11/90)
> Just to be fair, I should point out that it was a pretty low > priority (plot(1) command doesn't work). > I phoned the UK response centre a month or two ago and got a quick reply on the plot bug that occurs when running plot in an Apollo window: 'plot -Tapollo'. On a bsd4.3 system 'plot' looks in /sys5.3/usr/lib rather than /bsd4.3/usr/lib. Creating a link (amongst other methods) gets it working fine. However Apollo have been very slow in another bug I found concerning DIALOG and GMR. The Dialog manual states that locator_update events are sent to graphical applications which request locator information. However under 10.1 Dialog appears to be sending locator events instead. The effect of this is that when rubberbanding graphical objects, the objects dont keep up with the cursor. It is even possible for the input buffer to overflow, crashing the program. Apollos gm_draw in the Dialog domain_examples exhibits this rubberbanding delay. Has anyone else come across this problem?
bep@quintro.uucp (Bryan Province) (06/11/90)
In article <1990Jun7.170336.19246@terminator.cc.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >These lists are great. Now, does anyone have a list of what bugs they are >supposed to fix? I have a copy of the April patch tape release notes (9005). If anyone wants it they can reply to me and I would be willing to Email it to you but it is too large to post to the net. If I get a large number of requests I may post it anyway. -- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- Bryan Province Glenayre Corp. quintro!bep@lll-winken.llnl.gov Quincy, IL tiamat!quintro!bep@uunet "Surf Kansas, There's no place like home, Dude."