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

[Balazs Scheidler]

On Fri, 2011-06-03 at 10:14 +0200, Pal Tamas wrote:
> 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.

A better solution would be to remove the syslog-ng specific portion of
LD_LIBRARY_PATH env variable before executing user-supplied programs
(confgen, program source & destination). The issue is that it's not easy
to identify these points, and sometimes the exec() call itself is buried
under several layers (popen for instance). This issue only happens if
the env wrapper is enabled (--enable-env-wrapper), which is needed to
run syslog-ng in /opt/syslog-ng and is used by both the PE and OSE
binaries that we build.

Hmm... I think I'll just apply the patch, fixing the error message.

Thanks guys.

Here's the patch I've committed:

commit b7d46bc094215fa80f93e0dc46a3caa83e8a24b8
Author: Balazs Scheidler <bazsi at balabit.hu>
Date:   Sat Jun 4 12:54:07 2011 +0200

    Bail out on unknown systems, and use a clean environment.
    
    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>
    Signed-off-by: Balazs Scheidler <bazsi at balabit.hu>




-- 
Bazsi