[syslog-ng] [PATCH 6/7] [system source]: Bail out on unknown systems, and use a clean environment.

[Pal Tamas]

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 at 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 at 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 at balabit.hu