On Tue, Jul 6, 2010 at 5:58 PM, Rich Megginson <rmeggins at 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=8d483936b737314edcb837ea7eefedd8ad42000f 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
