Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
Larry Rosenman writes: Universal Practice does NOT equal Security and Usability. Please consider what Kean is saying here. What Kean is saying is that your system is insecure if you have a setuid executable that references shared libraries with nonabsolute sonames and you have a system (an older system) that contains a particular bug in its run-time dynamic loader that it obeys LD_LIBRARY_PATH for setuid executables. That is fairly common knowledge, and that's why LD_LIBRARY_PATH is ignored for setuid executables on all properly functioning operating systems. If your system is broken in that particular way, upgrade your system or don't use setuid programs at all. Those are the only sane choices. It is not an acceptable choice to disable all valid uses of nonabsolute sonames for all users, just because some users are running on broken systems with obvious security flaws. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
--On Friday, July 25, 2003 09:37:04 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: Larry Rosenman writes: Universal Practice does NOT equal Security and Usability. Please consider what Kean is saying here. What Kean is saying is that your system is insecure if you have a setuid executable that references shared libraries with nonabsolute sonames and you have a system (an older system) that contains a particular bug in its run-time dynamic loader that it obeys LD_LIBRARY_PATH for setuid executables. That is fairly common knowledge, and that's why LD_LIBRARY_PATH is ignored for setuid executables on all properly functioning operating systems. If your system is broken in that particular way, upgrade your system or don't use setuid programs at all. Those are the only sane choices. It is not an acceptable choice to disable all valid uses of nonabsolute sonames for all users, just because some users are running on broken systems with obvious security flaws. I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? All the SYSTEM SUPPLIED .so's on UnixWare use an absolute DT_SONAME, and I feel that we should build libpq to supply same on UnixWare, and Kean suggests that the prefered, SCO recommended way on OpenServer is to do the same. I belive that the issue is not broken systems, but broken practice. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
Larry Rosenman writes: I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? We can discuss adding the ability, but I'm against enforcing it by default. I belive that the issue is not broken systems, but broken practice. No, the issue is precisely that someone is proposing to break reasonable, useful practice to accomodate broken systems. No one is claiming that absolute sonames make the system more featureful or useful. In fact, it was admitted that it would have the reverse effect. The only argument for absolute sonames that was brought forth was that some older systems have security holes that can be worked around in this manner. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
--On Friday, July 25, 2003 11:58:18 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: Larry Rosenman writes: I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? We can discuss adding the ability, but I'm against enforcing it by default. I belive that the issue is not broken systems, but broken practice. No, the issue is precisely that someone is proposing to break reasonable, useful practice to accomodate broken systems. No one is claiming that absolute sonames make the system more featureful or useful. In fact, it was admitted that it would have the reverse effect. The only argument for absolute sonames that was brought forth was that some older systems have security holes that can be worked around in this manner. For an example of ADDING to the usefulness, UnixWare has no ld.so.conf, or ldconfig equivalent. For ALL my PostgreSQL apps, I either need to specify -R/usr/local/pgsql/lib on the EXECUTABLE build, or make sure there is a GLOBAL LD_LIBRARY_PATH environment variable set. The absolute DT_SONAME will fix that issue on THIS platform, which is why the ABILITY of an INDIVIDUAL port to set an absolute DT_SONAME would be useful. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
Finally I understand the issue, I think. But wouldn't an ordinary user on SCO wanting to install a private copy of Pg then have to hack the Makefiles to change/remove the abolute DT_SONAME? If so, that seems to me to mandate that this not be in the vanilla distribution. OS Vendors commonly make changes like this in software versions they distribute - that's a different thing from putting it in the standard distribution, ISTM. The benefit Larry cites seems to me to be small - presumably his Makefiles must include -L /usr/local/pgsql/lib, so adding -R /usr/local/pgsql/lib doesn't look like a big thing. Adding an Rpath to executables to use libs in non-standard locations is very common, surely? Maybe this needs to be YACO (yet another configure option) cheers andrew Larry wrote --On Friday, July 25, 2003 11:58:18 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: Larry Rosenman writes: I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? We can discuss adding the ability, but I'm against enforcing it by default. I belive that the issue is not broken systems, but broken practice. No, the issue is precisely that someone is proposing to break reasonable, useful practice to accomodate broken systems. No one is claiming that absolute sonames make the system more featureful or useful. In fact, it was admitted that it would have the reverse effect. The only argument for absolute sonames that was brought forth was that some older systems have security holes that can be worked around in this manner. For an example of ADDING to the usefulness, UnixWare has no ld.so.conf, or ldconfig equivalent. For ALL my PostgreSQL apps, I either need to specify -R/usr/local/pgsql/lib on the EXECUTABLE build, or make sure there is a GLOBAL LD_LIBRARY_PATH environment variable set. The absolute DT_SONAME will fix that issue on THIS platform, which is why the ABILITY of an INDIVIDUAL port to set an absolute DT_SONAME would be useful. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
Larry Rosenman wrote: If your system is broken in that particular way, upgrade your system or don't use setuid programs at all. Those are the only sane choices. It is not an acceptable choice to disable all valid uses of nonabsolute sonames for all users, just because some users are running on broken systems with obvious security flaws. I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? All the SYSTEM SUPPLIED .so's on UnixWare use an absolute DT_SONAME, and I feel that we should build libpq to supply same on UnixWare, and Kean suggests that the prefered, SCO recommended way on OpenServer is to do the same. I belive that the issue is not broken systems, but broken practice. It is a broken system. Setuid shouldn't honor that environment variable, because you are never going to be sure you catch all the shared library file creations. Also, once we hard code it, you can't move the library around later if you wish. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2] (fwd)
To keep this on the list. PG Core: I think Kean makes good points, and adding infrastructure to do it with absolute pathnames in the shared libs would be a GOOD thing, and let the OS Specific maintainer(s) enable as their current or future practice dictates. LER Forwarded Message Date: Thursday, July 24, 2003 04:33:12 -0700 From: Kean Johnston [EMAIL PROTECTED] To: Larry Rosenman [EMAIL PROTECTED] Cc: Peter Eisentraut [EMAIL PROTECTED] Subject: Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2] These concerns might have some merit, but the solution could not possibly be to only fix this on one platform, because the mechanisms are the same I was not trying to re-architect PostgreSQL's build system. I submitted a patch for a specific OS that made it behave the way the vendor (us) recommends you build things. If the PG folks dont want to accept the patch thats really quite OK with me I will just apply it myself every time there is a new release. I am not evangelizing for this to be a universal change, but I thiunk that decling the OS patch becuase all othr OSes haven't done the same thing is a wee bit harsh, but I have no emotional attachment to this issue. everywhere. That said, it seems the universal practice is not to put full sonames into shared libraries, so it seems better that our libraries follow that practice. Otherwise it will be only a matter of time before someone comes out of the wood and claims that libraries will full sonames are a big whatever-else problem. I mean no offence when I say that that is an extremely weak argument. It used to be universal practice that if you wanted a small pause in the kernel you could do: for (spin = 0; spin 100; spin++) ; And now optimizers and faster CPUs and whatever make that plainly wrong. But that aside I would also say that that position is wrong. libtool goes to some considerable lengths to figure out how to hard-code paths into shared libraries. It just rarely gets it right. Much of the wisdom about shared libraries these days comes from folks reading libtool's info page. Most people just dont care about the issue as long as it sorta-kinda works, so they just accept what they read. But libtool does many many things incorrectly, often in the name of expediency. Its not a bad program, it just has a different design goal. But I digress. If Peter agrees in principle that not having direct pathnames can be a problem then not at least taking the time to investigate or analyze the impact becuase of some potential future misunderstanding of the issue is a bit short-sighted. I can hear the halls of Microsoft ringing with hey lets not fix that bug, someone in the future will complain about it if we do, or chips will get so fast that people wont mind rebooting their OS every other mouse click :) Universal Practice does NOT equal Security and Usability. How true ... just look at sendmail :) *oops* ... was that my aloud voice? :) Kean -- End Forwarded Message -- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
Larry Rosenman writes: Why do this at all? Security. Having shared libraries without full SONAME's is a big security risk. There have been any number of huge explots based around this. Point me at any Solaris machine = 2.7, or any OSR5 system 507 or any FreeBSD system = 4.0 and I can get root with 1 tiny program thats on all of them: xterm. It has long upset me, and I am done trying to convince them, but libtool encourages the worst possible .so practices, and may programs seem to have picked up those equally bad practices. There is no need for futzing with ld.conf and the like if people take the time to construct shared libraries propperly. Yes it can be a pain to bootstrap but the reward is very well worth the effort it takes. These concerns might have some merit, but the solution could not possibly be to only fix this on one platform, because the mechanisms are the same everywhere. That said, it seems the universal practice is not to put full sonames into shared libraries, so it seems better that our libraries follow that practice. Otherwise it will be only a matter of time before someone comes out of the wood and claims that libraries will full sonames are a big whatever-else problem. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
--On Wednesday, July 23, 2003 12:20:34 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: Larry Rosenman writes: Why do this at all? Security. Having shared libraries without full SONAME's is a big security risk. There have been any number of huge explots based around this. Point me at any Solaris machine = 2.7, or any OSR5 system 507 or any FreeBSD system = 4.0 and I can get root with 1 tiny program thats on all of them: xterm. It has long upset me, and I am done trying to convince them, but libtool encourages the worst possible .so practices, and may programs seem to have picked up those equally bad practices. There is no need for futzing with ld.conf and the like if people take the time to construct shared libraries propperly. Yes it can be a pain to bootstrap but the reward is very well worth the effort it takes. These concerns might have some merit, but the solution could not possibly be to only fix this on one platform, because the mechanisms are the same everywhere. That said, it seems the universal practice is not to put full sonames into shared libraries, so it seems better that our libraries follow that practice. Otherwise it will be only a matter of time before someone comes out of the wood and claims that libraries will full sonames are a big whatever-else problem. Universal Practice does NOT equal Security and Usability. Please consider what Kean is saying here. Kean, Please respond. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
2nd followup from Kean. LER Forwarded Message Date: Friday, July 18, 2003 23:43:55 -0700 From: Kean Johnston [EMAIL PROTECTED] To: Larry Rosenman [EMAIL PROTECTED] Cc: Subject: Re: PG Patch Larry Rosenman wrote: I got a question from the PG Core Team (Bruce Momjian) about the rpathdir portion of your patch. Why can't it use libdir? Or can we wrap it in .if (port,=,sco) type stuff? Sorry I forgot to anwer that portion of the question. The only place that used RPATHDIR *is* wrapped up in if port=sco. But why not use just libdir? Well the rule for making shared libraries is shared across multiple makefiles. Although I only set it for the main interface libraries, I had originally set it for all the dynamically loadable modules too, and for those, libdir isnt what you want, you want datadir or whatever its called (I'm too lazy to go look now). So I needed variable the lower level makefiles could specify that get used in the top level makefile. Why do this at all? Security. Having shared libraries without full SONAME's is a big security risk. There have been any number of huge explots based around this. Point me at any Solaris machine = 2.7, or any OSR5 system 507 or any FreeBSD system = 4.0 and I can get root with 1 tiny program thats on all of them: xterm. It has long upset me, and I am done trying to convince them, but libtool encourages the worst possible .so practices, and may programs seem to have picked up those equally bad practices. There is no need for futzing with ld.conf and the like if people take the time to construct shared libraries propperly. Yes it can be a pain to bootstrap but the reward is very well worth the effort it takes. Suffice it to say that I believe that *EVERY* .so should have an absolute SONAME. There are still a few I need to clean up in 507 but most of them are correct. If you're not on the up-and-up with DT_RUNPATH, DT_RPATH and SONAME ELF headers I suggest for light reading that you peruse the gABI. Kean -- End Forwarded Message -- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] PG Patch (fwd)
More on the shared lib stuff. I'd LIKE to get a discussion of this (after just talking to Bruce on the phone). If I need to repost Kean's comments to -HACKERS, let me know. LER Forwarded Message Date: Saturday, July 19, 2003 13:50:55 -0700 From: Kean Johnston [EMAIL PROTECTED] To: Larry Rosenman [EMAIL PROTECTED] Cc: Subject: Re: PG Patch Larry Rosenman wrote: BTW, you mentioned gAPI, what's the un-TLA'ing of that, and a WWW ref? gABI - General Application Binary Interface. http://www.sco.com/developers/gabi Oh and this isnt a SCO-only thing, most UNIXes conform to it to varying degrees. Is the stuff you brought up the reason I always have to futz with LD_LIBRARY_PATH for the libpq.so on UnixWare7? Almost certainly. I havent looked at the UnixWare compile, but it too can be fixed by using -h with a full pathname, or at least using -R correctly, which is a workable but less preferable solution. Kean -- End Forwarded Message -- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
