3:52 p.m.
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.
--
--
Michael J. Smith
mjs(a)smithbowen.net
2:56 a.m.
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
11:07 a.m.
Thanks for the suggestions, folks!
On Mon, 7 Mar 2011 12:56:58 +0200
Buchan Milne <bgmilne(a)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(a)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?
--
--
Michael J. Smith
mjs(a)smithbowen.net
11:18 a.m.
New subject: Another thought on backends
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.
--
--
Michael J. "perlophobos" Smith
mjs(a)smithbowen.net
1:36 p.m.
New subject: Another thought on backends
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:33 p.m.
New subject: Another thought on backends
On Mon, 07 Mar 2011 13:36:45 -0800
Howard Chu <hyc(a)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 J. Smith
mjs(a)smithbowen.net
11:47 a.m.
New subject: Another thought on backends
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.
--
Hallvard
12:15 p.m.
New subject: Postgres perhaps - was Re: Another thought on backends
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
Chief Scientist, Science Tools Corporation
rtroy at ScienceTools.com, http://ScienceTools.com/
Chief Technical Officer, VP Engineering, eHealthTrust Corporation,
richard at eHealthTrust.com, http://eHealthTrust.com/
7:13 p.m.
New subject: Postgres perhaps - was Re: Another thought on backends
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
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11:49 a.m.
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
2:29 p.m.
On Mon, 7 Mar 2011 19:49:50 +0000
Andrew Findlay <andrew.findlay(a)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.
--
--
Michael J. Smith
mjs(a)smithbowen.net
3:10 a.m.
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
4468
days inactive
4477
days old
openldap-technical@openldap.org
11 comments
6 participants
participants (6)
-
Andrew Findlay -
Buchan Milne -
Hallvard B Furuseth -
Howard Chu -
Michael Smith -
Richard Troy