On Tue, Jul 6, 2010 at 5:58 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
Roberto Polli wrote:
>
> Hi all,
> our company decided to sponsor a Sabayon/Gentoo distribution of 389org.
>
> It seems that there are some issues in admin-server, which have been
> deeply investigated by the Sabayon maintainer.
>
> Those issues could be related to the latest versions of the libraries used
> in Gentoo; so the question:
> - did some of you test 389org on Fedora Linux or RHEL6?
>
Yes. I've just tested the latest 389-admin-1.1.11.rc1 and
389-ds-base-1.2.6.rc3 on Fedora rawhide (F-14)
This system uses httpd version 2.2.15 and apr 1.3.9
* yum install 389-ds
* setup-ds-admin.pl - use defaults
* launched the web browser -
http://localhost:9830/ - everything works fine
- main page, topology page, log viewer, etc. (including the CGI the
maintainer was having problems with, or at least I'm assuming this is the
same problem I was working on IRC with lxnay last week)
The problem seems specific to Gentoo
I've been able to track down the problem, also thanks to (you) and
people from httpd-dev.
It's either redhat/fedora packagers doing something at .spec level in
some library (it wouldn't be the first time) or there is something
error-prone in 389 codebase. Let me explain: httpd-devs suggested the
following change in password_pipe(): set PASSWORD_PIPE always to 1
(since the fd that PASSWORD_PIPE is pointing to is closed by mod_cgid
after a dup2() here
http://pastebin.com/2yTS4MU5 at line 98. This
makes libadminutil able to read from PASSWORD_PIPE fd (and not getting
EBADF). Unfortunately, at that point of the execution "stack", the fd
which libadminutil (distadm.c ADM_InitializePermissions()) expects to
gather data from returns "", like if something reset the read buffer.
Looking at strace output, I am unable to locate where the pipe leaks,
so I'm going to divide the code into chunks and analyze each chunk
separately. The ultimate issue is just that: a leaking pipe.
It can be caused by several reasons, maybe some newer library
introduced a behavior change. I'm running almost "bleeding edge" here,
Gentoo ~amd64 arch on the test machine: I have to in order to commit
389-ds packages in the unstable "branch" of Portage.
I produced an insecure patch, that makes (almost, still have to work
out AdminUtil.pm) htmladmin working properly, just to make sure that
the problem stands in the pipe() handling code.
See:
http://gitweb.sabayon.org/?p=overlay.git;a=commit;h=8d483936b737314edcb83...
look for *PASSWORD_PIPE*.patch
There are two options for such leak to take place: either O_CLOEXEC is
set or some error after the fork() that could stand between mod_cgid.c
and distadm.c.
Here I have:
apache-2.2.15 (worker MPM) + mod_cgid
apr-1.4.2
apr-util-1.3.9
glibc-2.10.1
linux-2.6.34 (and also tested on 2.6.33)
latest 389 packages (including rc releases)
>
> Peace,
> R.
>
--
Fabio Erculiani
http://www.sabayon.org
http://www.gentoo.org