Fabio Erculiani wrote: > On Tue, Jul 6, 2010 at 5:58 PM, Rich Megginson <rmeggins@xxxxxxxxxx> 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. > I'm not sure what the problem is. If we look at lines 96-98 of http://pastebin.com/2yTS4MU5: else if (attr->child_out) { dup2(attr->child_out->filedes, STDOUT_FILENO); // dup2 9, 1 apr_file_close(attr->child_out); // close 9 attr->child_out->filedes is 9 - this value is set at line 760 of mod_cgid.c: ((rc = apr_procattr_child_out_set(procattr, inout, NULL)) != APR_SUCCESS) || inout is set at line 733: apr_os_file_put(&inout, &sd2, 0, r->pool); sd2 is set at line 683: sd2 = accept(sd, (struct sockaddr *)&unix_addr, &len); Perhaps the httpd developers can tell me how it is possible for the fd returned by accept() to be the same fd as returned by line 623 in mod_admserv.c: rv = apr_file_pipe_create(&readp, &writep, r->pool); ? The only way I know is that the pipe fds are close()d before the call to accept. So why is this happening? As you say, one way is that the fds are set to FD_CLOEXEC by default on Gentoo but not on RHEL/Fedora. Not sure where/how that happens. I've looked at the Fedora rawhide spec and patches for httpd and apr - I don't see where this could be happening. Note that there is no O_CLOEXEC on RHEL/Fedora, only FD_CLOEXEC (at least, when I do this find /usr/include -type f -exec grep CLOEXEC {} /dev/null \; I only see FD_CLOEXEC) Another option is that apr_pool_cleanup_register(r->pool, (void *)((intptr_t)fd), close_pipe, apr_pool_cleanup_null); makes the close_pipe callback happen before mod_cgid has a chance to execute the CGI. Could the httpd devs explain how this could happen? The main thing is that password_pipe creates a pipe - no one else should be closing that 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. >>> >>> >> > > > > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
