On Thu, Jun 02, 2011 at 08:49:05PM +0200, Balazs Scheidler wrote:
On Mon, 2011-05-23 at 11:56 +0200, Gergely Nagy wrote:
From: Tamas Pal <folti@balabit.hu>
Force using OS's own uname implementation, over whatewer found in PATH. Die with error on an unsupported system or uname error.
Signed-off-by: Tamas Pal <folti@balabit.hu> --- scl/system/generate-system-source.sh | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/scl/system/generate-system-source.sh b/scl/system/generate-system-source.sh index d89fd33..6f5af70 100755 --- a/scl/system/generate-system-source.sh +++ b/scl/system/generate-system-source.sh @@ -23,6 +23,14 @@ # #############################################################################
+# DO NOT REMOVE!!! +# We have to force the script to use the OS's own utilities, instead of some +# random stuff found in path. This is needed when PATH points to a uname binary +# with some missing dependencies, due to LD_LIBRARY_PATH/LIBPATH settings. In those case, it's possible, that uname doesn't work... +PATH=/bin:/usr/bin:$PATH +LIBPATH= +LD_LIBRARY_PATH= +export PATH LIBPATH LD_LIBRARY_PATH
os=${UNAME_S:-`uname -s`} osversion=${UNAME_R:-`uname -r`}
Hmm... I really don't get this, what if the admin really want to change the uname binary? Can you explain when this is needed? It was an AIX specific bug. On the test system, there are another uname from GNU binutils under /opt/freeware/bin which depends on their own libintl library located in /opt/freeware/lib. Due to AIX's own shared library handling(see below: [1]), this conflicted with our libintl implementation, rendering the uname binary inoperable.
Because the script didn't handle the case when uname returns nothing or unsupported OS info, it returned neither system log sources nor warning to the user(other than catching the dynamic linker's error message on console). Other systems have more sane dynamic linkers and shared library handling policies, so it wouldn't cause the same problem, unless the system in question really messed up, but we can't do much about that. If your system's uname is broken (located in /bin or in case of UNIXes, /usr/bin - where /bin is a symlink to /usr/bin), then you have bigger problems than syslog-ng not working. Other possible future problems, if the system have some AppArmor or SELinux like security suite installed, which would prevent executing binaries in non-standard paths, unless configured otherwise. This can be a problem for SCL's own scripts too. [1]: AIX shared library handling: On AIX the .so files themselves are packaged into .a archives and the dynamic linker's default behaviour is to look for them in there. In this case, the GNU uname depended on libintl.so.1 in a file libintl.a. Due to the limitations of the dynamic linker, it only looks into the first <libname>.a file found on path, if that one doesn't contain the needed .so it fails. In that case, the first libintl.a it found (due to inheriting LIBPATH from syslog-ng) was our own in /opt/syslog-ng/lib containing only a libintl.so.8.
+ *) + # need to notify the user that something gone terribly wrong... + echo "$0: FATAL: unsupported OS ($os) or uname(1) error. Please call BalaBit's support" >&2 + exit 1 + ;;
hmm... most syslog-ng users would probably not have a support policy in place, so the error message should not advise that.
Umm yes, I only the PE version in mind when I write that message.
If you have information on the first question, I'll integrate the patch with a slight change in the message, so no need for an updated patch.
-- Pal Tamas/Folti folti@balabit.hu