Thanks for the suggestions, folks!
On Mon, 7 Mar 2011 12:56:58 +0200 Buchan Milne bgmilne@staff.telkomsa.net wrote:
What are the permissions of /usr/local/bin/backshell.sh ?
~# ls -l /usr/local/bin/backshell.sh -rwxr-xr-x 1 mike mike 95 2011-03-04 15:29 /usr/local/bin/backshell.sh
Problem is the same if I try to execute a system binary, e.g. /bin/echo.
And --
On Mon, 7 Mar 2011 11:10:57 +0000 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
On Sun, Mar 06, 2011 at 06:52:21PM -0500, Michael Smith wrote:
Slapd is running as the 'openldap' user. Does that user have a valid shell? (i.e. can you do 'su openldap' and get a usable prompt?) Without that, you probably cannot run shell scripts in most modern systems.
Try setting openldap's shell to /bin/bash in /etc/passwd
This sounded promising. I followed the advice above but alas, no improvement.
More oddities:
The problem still arises even if I don't use the -u and -g flags, i.e. I run slapd as root. Also, as noted above, it also happens if I try to run a binary rather than a script.
Is it possible that execve is objecting to some environment setting? I know bupkis about the internals of execve.
I guess my next step is to change the execve call in fork.c -- or no, I see it's an execv call, so it picks up the actual environment. Guess I could try changing it to execve and providing some minimal anodyne environment. Unless somebody else has a better idea?