Re: PG Patch (fwd) [openserver patch followup #2]
От | Larry Rosenman |
---|---|
Тема | Re: PG Patch (fwd) [openserver patch followup #2] |
Дата | |
Msg-id | 33790000.1059124950@lerlaptop.lerctr.org обсуждение исходный текст |
Ответ на | Re: PG Patch (fwd) [openserver patch followup #2] (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: PG Patch (fwd) [openserver patch followup #2]
Re: PG Patch (fwd) [openserver patch followup #2] |
Список | pgsql-patches |
--On Friday, July 25, 2003 09:37:04 +0200 Peter Eisentraut <peter_e@gmx.net> 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: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
В списке pgsql-patches по дате отправления: