Patch-ID# 100890-01 Keywords: localtime, fcvt, strxfrm, setlocale, fork, vfork, nl_langinfo, scanf, access, export, getpwuid, leak, collating, strcoll, strxfrm, strcmp, colldef, strcpy, strncpy, strcmp Synopsis: SunOS 4.1.3: domestic libc replacement Date: Feb/19/93 ******************************************************************************** This is the "domestic" version of the libc patch and should be given only to customers who are using the U.S. Encryption Kit. ******************************************************************************** PLEASE read the ENTIRE installation discussion before proceeding with the installation of this patch. ******************************************************************************** SunOS release: 4.1.3 Unbundled Product: Unbundled Release: Topic: jumbo patch to integrate CTE fixes to libc for 4.1.3 The "standard" SunOS combinations of static, dynamic, and profiled libc's are contained in this patch. In addition, a complete replacement for /usr/lib/shlib.etc has also been included. BugId's fixed with this patch: 1033104 1039485 1040829 1049421 1053431 1054748 1059039 1061777 1069726 1069731 1070565 1072740 1074633 1077337 1088455 1109666 Architectures for which this patch is available: sun4(all) Patches which may conflict with this patch: Obsoleted by: Problem Description: 1033104 When /etc/hosts.equiv file begins with -@netgroup, any machine gets equiv access 1039485 ypserv goes into infinite loop and hangs server and its clients 1040829 sparc strcpy/strncpy causes core dump near page boundaries 1049421 localtime.c writes a null byte 1 byte beyond allocated space 1053431 innetgr may acknowledge false netgroup membership 1054748 ftp, ping dump core when connecting to a host with multiple DNS A records 1059039 memory leak using getpwuid(3) on a host that uses NIS 1061777 tzset has a memory leak 1069726 nl_langinfo(D_T_FMT) returns NULL if setlocale defaulted to "C" locale 1069731 long format strings for sscanf, fscanf, and scanf cause data corruption 1070565 c compiler stores wrong data for double 1072740 strcoll() .... strxfrm() dumps core for locale >< C if stdin closed 1074633 strcmp gets bad result when 0x80 char put in string. 1077337 xlock crashes when handling many return keypresses leaving system open 1088455 strcoll returns bad results when collating spec exhausts single char matrix 1109666 pclose() will hang if pipes break in unexpected order INSTALL: The parts list for this patch is listed below. lib/libc.a lib/libc_p.a lib/libc.sa18 (gets installed as lib/libc.sa.1.8) lib/libc.so18 (gets installed as lib/libc.so.1.8) 5lib/libc.a 5lib/libc_p.a 5lib/libc.sa28 (gets installed as 5lib/libc.sa.2.8) 5lib/libc.so28 (gets installed as 5lib/libc.so.2.8) lib/shlib.etc/lorder-sparc lib/shlib.etc/objsort lib/shlib.etc/Makefile lib/shlib.etc/README lib/shlib.etc/awkfile lib/shlib.etc/libc_pic.a lib/shlib.etc/libcs5_pic.a lib/debug/malloc.o lib/debug/mallocmap.o lib/libbsdmalloc.a The libraries in this patch may be placed in any directory. But if you choose to place any libc.* in a location other than /usr/lib or /usr/5lib, you'll have to use the -L flag with each ld execution to "point" to the chosen directory that holds these substitutes. Since this is likely to be a somewhat awkward requirement, the patch and the following install sequence assume you wish to substitute your standard libraries with the patched versions. The installation of ANY of the library parts may be done while the system is running, EXCEPT for the SHARED libc's. It is SAFEST to substitute the shared libraries while SunOS is booted in single-user mode or from the SunOS Installation miniroot. Since using SunOS in single-user mode is easier than booting the miniroot off the SunOS Installation tapes, the install sequence below will reference single-user mode. There is one more consideration. The installation sequence below will overwrite ALL libc "variants" in /usr/lib and /usr/5lib. If you have added/substituted parts to libc.a or libc.s?.X.Y in /usr/lib and/or /usr/5lib, you will need to 1) preserve these copies, or 2) plan to resubstitute your material in with these patch versions. It is highly recommended that you "walkthru" the installation sequence below to become familiar with what is being done prior to actually doing it. You can vary and even skip some steps in these instructions if you're *confident* you understand what is going on. Bear in mind that /usr/lib/libc.so.X.Y dynamically binds the *entire* SunOS and any corruption to this particular library will render a system virtually useless. Installing the libc patch: (perform the following steps in this order) o save patch distribution under some directory, say '/tmp/X'. o cd /tmp/X o su o (ensure no users are actively using any libc's) o mv /usr/lib/libc.a /usr/lib/libc.a.FCS o mv /usr/lib/libc_p.a /usr/lib/libc_p.a.FCS (1) o mv /usr/5lib/libc.a /usr/5lib/libc.a.FCS (2) o mv /usr/5lib/libc_p.a /usr/5lib/libc_p.a.FCS (2) o mv /usr/lib/libbsdmalloc.a /usr/lib/libbsdmalloc.a.FCS (1) if you do not have this file on your system, then the "Debugging" part of the OS distribution tape has not been loaded. (2) if you do not have this file on your system, then the "SystemV" part of the OS distribution tape has not been loaded. You will rename your original shared libc's at a later point in the installation. o mv /usr/lib/shlib.etc /usr/lib/shlib.etc.FCS o mkdir /usr/lib/shlib.etc o chmod g+s /usr/lib/shlib.etc These above 3 steps may be done if you wish to preserve completely your original /usr/lib/shlib.etc. If not, you may skip them. o mv /usr/lib/debug /usr/lib/debug.FCS o mkdir /usr/lib/debug o chmod g+s /usr/lib/debug These above 3 steps may be done if you wish to preserve completely your original /usr/lib/debug. If not, you may skip them. o cp -p -R `arch`/* /usr The arch command returns either sun3 or sun4. So you are actually copying all the files in the respective directory to /usr. If you followed all steps mentioned above you are still in /tmp/X. o "quiet" system (have users log off,announce system going down,...) o sync o halt o >b[oot] vmunix -s You're now booting SunOS in single-user mode. We will rename the shared libc's to make them "active" and this is best done, at minimum, under single-user. o cd /usr/lib o ls -l libc.s* You will get an output similar to the following: -rw-r--r-- 1 root 7996 Feb 8 1990 libc.sa.1.8 -rwxr-xr-x 1 root 516096 Feb 8 1990 libc.so.1.8 -rw-r--r-- 1 root 7996 Oct 4 05:00 libc.sa18 -rw-r--r-- 1 root 516096 Oct 4 05:13 libc.so18 o sync o mv libc.so.1.8 libc.so.1.8.FCS this saves the original file o mv libc.so18 libc.so.1.8 this copies the patch to its new place o mv libc.sa.1.8 libc.sa.1.8.FCS this saves the original file o mv libc.sa18 libc.sa.1.8 this copies the patch to its new place o date Do this last step CAREFULLY. IF the 'date' command does *anything* else but show a proper date, then IMMEDIATELY do: o mv libc.so.1.8 libc.so18 o mv libc.so.1.8.FCS libc.so.1.8 o mv libc.sa.1.8 libc.sa18 o mv libc.sa.1.8.FCS libc.sa.1.8 If the date command is successful, continue here: o cd ../5lib o ls -l libc.s* You will get an output similar to the following: -rw-r--r-- 1 root 7996 Feb 8 1990 libc.sa.2.8 -rwxr-xr-x 1 root 516096 Feb 8 1990 libc.so.2.8 -rw-r--r-- 1 root 7996 Oct 4 05:00 libc.sa28 -rw-r--r-- 1 root 524288 Oct 4 05:15 libc.so28 o mv libc.so.2.8 libc.so.2.8.FCS this saves the original file o mv libc.so28 libc.so.2.8 this copies the patch to its new place o mv libc.sa.2.8 libc.sa.2.8.FCS this saves the original file o mv libc.sa28 libc.sa.2.8 this copies the patch to its new place Do this last step CAREFULLY also. o ranlib -t /usr/lib/libc* o ranlib -t /usr/5lib/libc* In these two ranlib commands you will see not an archive: ........ error message for all the libc.so* files. You can disregard them. It saves a lot of typing when you supply the "*" wildcard instead of typing in the ".a" and ".sa." filenames. o ^D The install is complete. The ^D above terminates single-user mode, and brings your system back up in multi-user mode. <<<<<<<<<<<<<<<<<< end README >>>>>>>>>>>>>>>>>>>>>>