Hello all. I'm working with openLDAP again, after some years' hiatus, and very glad of it.
I'm having a problem which I hope somebody's seen before. I'm trying to use back-shell (to avoid relearning Perl) for a quick-and dirty solution to a problem too tedious to describe here.
Here's the relevant bits of slapd.conf:
-------------- moduleload back_shell.la backend shell database shell suffix "dc=foo,dc=bar,dc=com" rootdn "cn=admin,dc=foo,dc=bar,dc=com" rootpw secretissimum-secretissimorum
add /usr/local/bin/backshell.sh bind /usr/local/bin/backshell.sh compare /usr/local/bin/backshell.sh delete /usr/local/bin/backshell.sh modify /usr/local/bin/backshell.sh modrdn /usr/local/bin/backshell.sh search /usr/local/bin/backshell.sh unbind /usr/local/bin/backshell.sh
syncrepl rid=123 provider=ldap://127.0.0.1 type=refreshOnly interval=00:00:00:05 searchbase="dc=foo,dc=bar,dc=com" scope=sub bindmethod=simple binddn="uid=mik,ou=Managers,dc=foo,dc=bar,dc=com" credentials="M0$tsecret"
-------------
backshell.sh is moronically simple at the moment: ---------------- #!/bin/bash while read LINE do /bin/echo $LINE >>/var/lib/ldap2/replog.txt done echo RESULT ----------------
Commands to execute slapd: ~$ sudo su # /usr/sbin/slapd -d 0x4400 -f /etc/ldap/slapd2.conf -h "ldap://127.0.0.1:3889" -u openldap -g openldap ---------------
Varia:
~$ which bash /bin/bash ~$ ls -ld /var/lib/ldap2 drwxr-xr-x 2 openldap openldap 4096 2011-03-04 13:10 /var/lib/ldap2
Debug output from slapd:
@(#) $OpenLDAP: slapd 2.4.9 (Jul 30 2010 00:42:11) $ buildd@vernadsky:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd WARNING: No dynamic config support for database shell. slapd starting syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=123 inserted UUID f25a0996-d888-102f-9c2e-559808098a6b execv failed shell: fgets failed: Success (0) str2result () expecting "RESULT" ---------------------
... over and over again.
strace says:
[pid 19068] execve("/usr/local/bin/backshell.sh", ["/usr/local/bin/backshell.sh"], ["SHELL=/bin/bash", "TERM=xterm", "USER=root", "LS_COLORS=no=00:fi=00:di=01;34:l"..., "SUDO_USER=mike", "SUDO_UID=1001", "USERNAME=root", "PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", "PWD=/home/mike", "LANG=en_US.UTF-8", "SHLVL=1", "SUDO_COMMAND=/bin/su", "HOME=/root", "LOGNAME=root", "LESSOPEN=| /usr/bin/lesspipe %s", "SUDO_GID=1001", "LESSCLOSE=/usr/bin/lesspipe %s %"..., "_=/usr/sbin/slapd"]) = -1 EACCES (Permission denied)
-------------
Doesn't look like it's even able to execute my little program, right?
So this may be more a question about the subtleties of execve (and possibly its interactions with sudo?) than about openldap, but if some kind soul can set me on the right path, I'd be most grateful. I've manpaged and googled everything I could think of, and drawn a blank.
On Monday, 7 March 2011 01:52:21 Michael Smith wrote: buildd@vernadsky:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slap
d WARNING: No dynamic config support for database shell. slapd starting syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=123 inserted UUID f25a0996-d888-102f-9c2e-559808098a6b execv failed shell: fgets failed: Success (0) str2result () expecting "RESULT"
... over and over again.
strace says:
[pid 19068] execve("/usr/local/bin/backshell.sh", ["/usr/local/bin/backshell.sh"], ["SHELL=/bin/bash", "TERM=xterm", "USER=root", "LS_COLORS=no=00:fi=00:di=01;34:l"..., "SUDO_USER=mike", "SUDO_UID=1001", "USERNAME=root", "PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", "PWD=/home/mike", "LANG=en_US.UTF-8", "SHLVL=1", "SUDO_COMMAND=/bin/su", "HOME=/root", "LOGNAME=root", "LESSOPEN=| /usr/bin/lesspipe %s", "SUDO_GID=1001", "LESSCLOSE=/usr/bin/lesspipe %s %"..., "_=/usr/sbin/slapd"]) = -1 EACCES (Permission denied)
Doesn't look like it's even able to execute my little program, right?
So this may be more a question about the subtleties of execve (and possibly its interactions with sudo?) than about openldap, but if some kind soul can set me on the right path, I'd be most grateful. I've manpaged and googled everything I could think of, and drawn a blank.
What are the permissions of /usr/local/bin/backshell.sh ?
Regards, Buchan
On Sun, Mar 06, 2011 at 06:52:21PM -0500, Michael Smith wrote:
Commands to execute slapd: ~$ sudo su # /usr/sbin/slapd -d 0x4400 -f /etc/ldap/slapd2.conf -h "ldap://127.0.0.1:3889" -u openldap -g openldap
[pid 19068] execve("/usr/local/bin/backshell.sh", ["/usr/local/bin/backshell.sh"], ["SHELL=/bin/bash", "TERM=xterm", "USER=root", "LS_COLORS=no=00:fi=00:di=01;34:l"..., "SUDO_USER=mike", "SUDO_UID=1001", "USERNAME=root", "PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", "PWD=/home/mike", "LANG=en_US.UTF-8", "SHLVL=1", "SUDO_COMMAND=/bin/su", "HOME=/root", "LOGNAME=root", "LESSOPEN=| /usr/bin/lesspipe %s", "SUDO_GID=1001", "LESSCLOSE=/usr/bin/lesspipe %s %"..., "_=/usr/sbin/slapd"]) = -1 EACCES (Permission denied)
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
Andrew
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?
Anybody interested in collaborating on a back-python analogous to back-perl? After a cursory glance at the code for the latter, it looks like it wouldn't be hard to adapt for the Python case.
On Mon, Mar 07, 2011 at 02:07:36PM -0500, Michael Smith wrote:
~# ls -l /usr/local/bin/backshell.sh -rwxr-xr-x 1 mike mike 95 2011-03-04 15:29 /usr/local/bin/backshell.sh
I assume that you can actually execute that from the command-line... (As the openldap user).
Problem is the same if I try to execute a system binary, e.g. /bin/echo.
Do you have AppArmor or SELinux enabled? A security framework of that sort might well prevent slapd from executing other programs.
Are any of your filesystems mounted with the 'noexec' flag?
Try doing 'cd /' before starting slapd - I notice that your original post had it starting in your own homedir, which might not be readable to the openldap user (so it could not do 'pwd' for example).
Andrew
Michael Smith wrote:
Anybody interested in collaborating on a back-python analogous to back-perl? After a cursory glance at the code for the latter, it looks like it wouldn't be hard to adapt for the Python case.
Go ahead if you like. Though it may be simpler to just use back-sock.
On Mon, 7 Mar 2011 19:49:50 +0000 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
Do you have AppArmor or SELinux enabled? A security framework of that sort might well prevent slapd from executing other programs.
Hooray! That was it! Either my distro (Ubuntu server) incorporates an apparmor file automatically withe its openLDAP package, or it's another sad case of Dueling Sysadmins. Anyway, it's now working just as advertised.
I'm such a Bronze-Age Unix guy I don't even think of things like apparmor unless I happen to have installed 'em myself.
Many many thanks.
On Mon, 07 Mar 2011 13:36:45 -0800 Howard Chu hyc@symas.com wrote:
Go ahead if you like. Though it may be simpler to just use back-sock.
*Blush*. And so it would. I didn't even know there *was* a back-sock; the openLDAP version I installed with the distro package tool doesn't seem to incorporate it, and I've been away for a while. Thanks.
Michael Smith writes:
Anybody interested in collaborating on a back-python analogous to back-perl? After a cursory glance at the code for the latter, it looks like it wouldn't be hard to adapt for the Python case.
I started on that once, but quit because Python and slapd both want their conflicting autoconf-generated files #included: OpenLDAP's portable.h vs. Python's pyconfig.h. back-perl escapes that: Perl uses metaconfig instead of autoconf.
On Mon, 14 Mar 2011, Hallvard B Furuseth wrote:
Michael Smith writes:
Anybody interested in collaborating on a back-python analogous to back-perl? After a cursory glance at the code for the latter, it looks like it wouldn't be hard to adapt for the Python case.
I started on that once, but quit because Python and slapd both want their conflicting autoconf-generated files #included: OpenLDAP's portable.h vs. Python's pyconfig.h. back-perl escapes that: Perl uses metaconfig instead of autoconf.
I have no interest with what you are proposing but I am very interested in porting OpenLDAP to Postgres. The compelling use case is that now, with the advent of binary replication in Postgres 9, one can replicate your Posgres installation - which you may be doing for any number of other reasons - and have that replication carry with it the OpenLDAP dataset. So, it reduces the systems management / maintenance overhead while increasing security (one DB system instead of two). Also, the Postgres replication is _very_ efficient and has no inherent limit on the number of replicants, each of which can be used for query-only, if desired.
It's my understanding that someone has already done this - ported OpenLDAP to Postgres, and there's a web page describing it out there somewhere. I have been looking for some free time (yeah, like _that's_ going to happen any time soon!) to do the port. And since I haven't quite gotten around to it, I'm wondering if there's general interest? Anyone?
Regards, Richard
Richard Troy wrote:
On Mon, 14 Mar 2011, Hallvard B Furuseth wrote:
Michael Smith writes:
Anybody interested in collaborating on a back-python analogous to back-perl? After a cursory glance at the code for the latter, it looks like it wouldn't be hard to adapt for the Python case.
I started on that once, but quit because Python and slapd both want their conflicting autoconf-generated files #included: OpenLDAP's portable.h vs. Python's pyconfig.h. back-perl escapes that: Perl uses metaconfig instead of autoconf.
I have no interest with what you are proposing but I am very interested in porting OpenLDAP to Postgres. The compelling use case is that now, with the advent of binary replication in Postgres 9, one can replicate your Posgres installation - which you may be doing for any number of other reasons - and have that replication carry with it the OpenLDAP dataset. So, it reduces the systems management / maintenance overhead while increasing security (one DB system instead of two). Also, the Postgres replication is _very_ efficient and has no inherent limit on the number of replicants, each of which can be used for query-only, if desired.
It's my understanding that someone has already done this - ported OpenLDAP to Postgres, and there's a web page describing it out there somewhere. I have been looking for some free time (yeah, like _that's_ going to happen any time soon!) to do the port. And since I haven't quite gotten around to it, I'm wondering if there's general interest? Anyone?
Are you saying there's a low level Postgres-specific API that can be leveraged? If you're just going to use SQL or something euqivalent, I don't see any advantage to that.
Regards, Richard
openldap-technical@openldap.org
-
Andrew Findlay -
Buchan Milne -
Hallvard B Furuseth -
Howard Chu -
Michael Smith -
Richard Troy