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 <bugs@RT-11.MIT.EDU>; 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" <basch@MIT.EDU>
Reply-To: basch@MIT.EDU, basch@Lehman.COM
To: krb5-bugs@MIT.EDU
Cc: krbcore@MIT.EDU
Subject: SunOS 4.1.x patches
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 <fcntl.h>
-#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;'
;;
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 <bugs@RT-11.MIT.EDU>; 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" <basch@MIT.EDU>
Reply-To: basch@MIT.EDU, basch@Lehman.COM
To: krb5-bugs@MIT.EDU
Cc: krbcore@MIT.EDU
Subject: SunOS 4.1.x patches
Show quoted text
>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.>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:
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 <fcntl.h>
-#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;'
;;
Show quoted text
------- 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
From: Tom Yu <tlyu@MIT.EDU>
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" <basch@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
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:
--
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 <tlyu@MIT.EDU>
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
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" <basch@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
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:
> 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.
--
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:
>Fix:
>Audit-Trail:
From: Tom Yu <tlyu@MIT.EDU>
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" <basch@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
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
> $(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 <tlyu@MIT.EDU>
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 <basch@MIT.EDU> 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).
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" <basch@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
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 <basch@MIT.EDU> 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).
> > 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: