[389-users] Sabayon/Gentoo distribution of 389org

Fabio Erculiani lxnay at gentoo.org
Tue Jul 6 16:34:08 UTC 2010


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



More information about the 389-users mailing list