Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) X-RT-Original-Encoding: iso-8859-1 Content-Length: 10063 From probe@k9.lehman.com Thu Jan 27 00:35:13 2000 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.mit.edu (8.9.3/8.9.3) with SMTP id AAA28726 for ; Thu, 27 Jan 2000 00:35:09 -0500 (EST) Received: from smtp7.atl.mindspring.net by MIT.EDU with SMTP id AA06615; Thu, 27 Jan 00 00:34:11 EST Received: from k9.lehman.com (pool-207-205-160-10.nwrk.grid.net [207.205.160.10]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id AAA30033; Thu, 27 Jan 2000 00:34:39 -0500 (EST) Received: from tardis.basch.net (root@tardis.basch.net [192.168.98.2]) by k9.lehman.com (8.8.7/8.8.7) with ESMTP id AAA03612; Thu, 27 Jan 2000 00:34:01 -0500 Received: (from probe@localhost) by tardis.basch.net (8.9.3/8.8.7) id AAA07742; Thu, 27 Jan 2000 00:34:00 -0500 Message-Id: <14479.55083.25237.229443@tardis.basch.net> Date: Thu, 27 Jan 2000 00:33:59 -0500 (EST) From: "Richard Basch" Reply-To: basch@MIT.EDU, basch@Lehman.COM To: krb5-bugs@MIT.EDU Cc: krbcore@MIT.EDU Subject: SunOS 4.1.x patches >Number: 819 >Category: krb5-build >Synopsis: SunOS 4.1.x patches >Confidential: yes >Severity: serious >Priority: medium >Responsible: krb5-unassigned >State: open >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Thu Jan 27 00:36:00 EST 2000 >Last-Modified: Tue Feb 22 16:27:41 EST 2000 >Originator: Richard Basch >Organization: >Release: >Environment: >Description: There are two problems with the tree for SunOS 4.x. 1. kinit fails because fcntl-style locks on SunOS do not work with tmpfs. flock-style locks work universally on SunOS. 2. Building shared libraries does not work because: - LD_LIBRARY_PATH is insufficient (/bin/ld ignores it in lieu of -L) - You need to assert that symbols may not be resolved Even with these patches, you have to be sure that you don't have too old of a version in the destination directory (it is better to remove it from the destination directory, at least temporarily). Unfortunately, it is either that or be subject to other attacks because of an even worse path ordering problem in the libraries. Enclosed are patches to: src/lib/krb5/os/lock_file.c src/aclocal.m4 I wish SunOS would go away, but it still is quite prevalent within the financial services industry and the DoD. -Richard Index: src/lib/krb5/os/lock_file.c =================================================================== RCS file: /home/ue-cvs/krb5/src/lib/krb5/os/lock_file.c,v retrieving revision 1.1.1.2 retrieving revision 1.2 diff -u -r1.1.1.2 -r1.2 --- lock_file.c 1999/12/17 20:48:09 1.1.1.2 +++ lock_file.c 2000/01/27 05:24:26 1.2 @@ -42,10 +42,13 @@ #ifdef HAVE_FCNTL_H #include -#endif -#if defined(HAVE_FCNTL_H) && defined(F_SETLKW) && defined(F_RDLCK) +#if defined(HAVE_FLOCK) && (defined(sun) && !defined(__svr4__)) +#define USE_FLOCK +#endif +#if !defined(USE_FLOCK) && defined(F_SETLKW) && defined(F_RDLCK) #define POSIX_FILE_LOCKS +#endif #endif #ifdef HAVE_FLOCK Index: src/aclocal.m4 =================================================================== RCS file: /home/ue-cvs/krb5/src/aclocal.m4,v retrieving revision 1.1.1.2 retrieving revision 1.2 diff -u -r1.1.1.2 -r1.2 --- aclocal.m4 1999/12/17 20:43:40 1.1.1.2 +++ aclocal.m4 2000/01/27 05:22:57 1.2 @@ -1134,10 +1134,10 @@ # under SunOS; the explicit setting of LD_LIBRARY_PATH does # does not make it into the output file, while directories # passed by "-Ldirname" do. - LDCOMBINE='LD_LIBRARY_PATH=`echo $(SHLIB_DIRS) | sed -e "s/-L//g" -e "s/ /:/g"` ld -dp -assert pure-text' + LDCOMBINE='LD_LIBRARY_PATH=`echo $(SHLIB_DIRS) | sed -e "s/-L//g" -e "s/ /:/g"` ld -dp -assert pure-text -assert nodefinitions' SHLIB_EXPFLAGS='-L$(SHLIB_RDIRS) $(SHLIB_EXPLIBS)' PROFFLAGS=-pg - CC_LINK_SHARED='LD_LIBRARY_PATH=`echo $(PROG_LIBPATH) | sed -e "s/-L//g" -e "s/ /:/g"` $(PURE) $(CC) -L$(PROG_RPATH)' + CC_LINK_SHARED='LD_LIBRARY_PATH=`echo $(PROG_LIBPATH) | sed -e "s/-L//g" -e "s/ /:/g"` $(PURE) $(CC) -L$(PROG_RPATH) $(PROG_LIBPATH)' CC_LINK_STATIC='LD_LIBRARY_PATH=`echo $(PROG_LIBPATH) | sed -e "s/-L//g" -e "s/ /:/g` $(PURE) $(CC)' RUN_ENV='LD_LIBRARY_PATH=`echo $(PROG_LIBPATH) | sed -e "s/-L//g" -e "s/ /:/g"`; export LD_LIBRARY_PATH;' ;; ------- end of forwarded message ------- -- Richard Basch AVP, Distributed Engineering URL: http://web.mit.edu/~basch Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu 101 Hudson St., 28th Floor Voice: +1 201 524 5049 Jersey City, NJ 07302-3988 Fax: +1 201 524 2111 >How-To-Repeat: >Fix: >Audit-Trail: From: Tom Yu To: basch@MIT.EDU Cc: basch@Lehman.COM, krb5-bugs@MIT.EDU, krbcore@MIT.EDU Subject: Re: pending/819: SunOS 4.1.x patches Date: 01 Feb 2000 17:28:00 -0500 So... what I'm failing to understand is why you've added $(PROG_LIBPATH) to CC_LINK_SHARED. Does cc fail to find the in-tree versions of the shared libraries if you put them in LD_LIBRARY_PATH rather than in -L flags? ---Tom From: "Richard Basch" To: Tom Yu Cc: krb5-bugs@MIT.EDU, krbcore@MIT.EDU Subject: Re: pending/819: SunOS 4.1.x patches Date: Tue, 1 Feb 2000 19:26:06 -0500 (EST) Correct... Using LD_LIBRARY_PATH failed to find the libraries. I figure keeping the environment variable set might still be useful in case there are "multiple" versions of the linker (after all, there is nothing to say that GNU ld or a version of ld from one of the SunPro suites isn't being used). -Richard On , 1-February-2000, "Tom Yu" wrote to "basch@MIT.EDU, basch@Lehman.COM, krb5-bugs@MIT.EDU, krbcore@MIT.EDU" saying: > So... what I'm failing to understand is why you've added > $(PROG_LIBPATH) to CC_LINK_SHARED. Does cc fail to find the in-tree > versions of the shared libraries if you put them in LD_LIBRARY_PATH > rather than in -L flags? > > ---Tom -- Richard Basch AVP, Distributed Engineering URL: http://web.mit.edu/~basch Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu 101 Hudson St., 28th Floor Voice: +1 201 524 5049 Jersey City, NJ 07302-3988 Fax: +1 201 524 2111 From: Tom Yu To: basch@MIT.EDU Cc: basch@lehman.COM, krb5-bugs@MIT.EDU, krbcore@MIT.EDU Subject: Re: pending/819: SunOS 4.1.x patches Date: 01 Feb 2000 22:02:48 -0500 >>>>> "basch" == Richard Basch writes: basch> Correct... Using LD_LIBRARY_PATH failed to find the libraries. basch> I figure keeping the environment variable set might still be basch> useful in case there are "multiple" versions of the linker basch> (after all, there is nothing to say that GNU ld or a version of basch> ld from one of the SunPro suites isn't being used). That's interesting. I don't remember that being a problem when I've been working with SunOS, but maybe I'm confused. Also, my impression was that all -L flags would get written into the binary, thus resulting in possible relative library search paths ending up in your binary, which is hardly a good thing. ---Tom From: "Richard Basch" To: Tom Yu Cc: krb5-bugs@MIT.EDU, krbcore@MIT.EDU Subject: Re: pending/819: SunOS 4.1.x patches Date: Wed, 2 Feb 2000 07:30:11 -0500 (EST) Correct again. All -L paths are written into the binary, so my choice to avoid most security holes was to put the "production" path first, and the development path second. This allows you to build on a system that does not have the production path and then to deploy it. Unfortunately, I was unable to get any other option to work. Since my default shell is "bash" and while make tends to prefer to use "sh", my default shell wasn't the cause of the compilation problems (bash uses the same "env=val command" syntax that sh allows). I used /bin/ld on a 4.1.4 system, and the procedure should accomodate the system's default ld. I tried both gcc and various SunPRO compilers, though I knew they were all configured to use the system's /bin/ld command. In essence, while LD_LIBRARY_PATH may work on some systems (and I also recall that at one time it did), it doesn't work with all versions of /bin/ld. Therefore, to make the build generally work on SunOS, the only choice is to also include the relative paths, or to completely change the build procedure such that you build a section, install a section, build the next section, etc... If the relative path is after the production path, it is hard to subvert as long as the production path cannot be "tampered" with. -Richard On , 1-February-2000, "Tom Yu" wrote to "basch@MIT.EDU, basch@lehman.COM, krb5-bugs@MIT.EDU, krbcore@MIT.EDU" saying: > >>>>> "basch" == Richard Basch writes: > > basch> Correct... Using LD_LIBRARY_PATH failed to find the libraries. > basch> I figure keeping the environment variable set might still be > basch> useful in case there are "multiple" versions of the linker > basch> (after all, there is nothing to say that GNU ld or a version of > basch> ld from one of the SunPro suites isn't being used). > > That's interesting. I don't remember that being a problem when I've > been working with SunOS, but maybe I'm confused. Also, my impression > was that all -L flags would get written into the binary, thus > resulting in possible relative library search paths ending up in your > binary, which is hardly a good thing. > > ---Tom -- Richard Basch AVP, Distributed Engineering URL: http://web.mit.edu/~basch Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu 101 Hudson St., 28th Floor Voice: +1 201 524 5049 Jersey City, NJ 07302-3988 Fax: +1 201 524 2111 Responsible-Changed-From-To: gnats-admin->krb5-unassigned Responsible-Changed-By: raeburn Responsible-Changed-When: Tue Feb 22 16:27:26 2000 Responsible-Changed-Why: Reformatted, changed topic. >Unformatted: