chroot'd operation, userid
by Howard Chu
I was reviewing the discussion of ITS#4719 and thinking about some of
the options. We could add a setuser/setgroup config directive for the
tools to use. It might be confusing since these directives would not
replace the need for slapd's -u and -g commandline options.
Along those lines, how does anyone use slapd with the -r option? Since
no corresponding option exists for the tools, and presumably the
pathnames in slapd.conf are absolute paths, I guess you would need an
alternate config for running the tools outside the chroot jail, with the
full paths to the jailed directories. Seems rather messy.
I would expect the more common scenario is to just run slapd using a
userID that doesn't have write privileges outside its database
directories, and not worry about a chroot jail.
We've talked about this in the past - why don't we restructure things so
that the user and group are read from the config, along with the
listeners? I.e., defer dropping root privs until after the config has
been read.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 6 months
[Fwd: BerkeleyDB region size bug]
by Howard Chu
This is Sleepycat bug #14908. I thought I posted it here before but
apparently not. Fixed in current 4.5.20, but still broken in all earlier
releases.
-------- Original Message --------
Subject: region size bug Re: [BDB-Alpha] Berkeley DB 4.5.8 ALPHA
Date: Mon, 10 Jul 2006 13:37:33 -0700
From: Howard Chu <hyc(a)symas.com>
To: support(a)sleepycat.com
CC: support(a)symas.com
References: <45A742B5-7DD5-4512-A204-A10FE8FC5DFC(a)oracle.com>
I just ran into this in 4.2.52 but the same calculation occurs in 4.4
and 4.5.8 alpha:
This computation gives the wrong results when the number of cache
regions is greater than the number of gigabytes (which we encounter on
Linux using shared memory regions, which are constrained to much smaller
than a gigabyte each).
in mp/mp_region.c:
roff_t reg_size;
/* Figure out how big each cache region is. */
reg_size = (roff_t)(dbenv->mp_gbytes / dbenv->mp_ncache) * GIGABYTE;
reg_size += ((roff_t)(dbenv->mp_gbytes %
dbenv->mp_ncache) * GIGABYTE) / dbenv->mp_ncache;
reg_size += dbenv->mp_bytes / dbenv->mp_ncache;
*reg_sizep = reg_size;
The first reg_size calculation always goes to zero when mp_ncache >
mp_gbytes.
This should have been, instead:
reg_size = GIGABYTE / dbenv->mp_ncache * dbenv->mp_gbytes;
Or in unidiff:
--- mp_region.c.O 2006-06-19 08:37:58.000000000 -0700
+++ mp_region.c 2006-07-10 13:36:43.000000000 -0700
@@ -260,9 +260,7 @@
roff_t reg_size;
/* Figure out how big each cache region is. */
- reg_size = (roff_t)(dbenv->mp_gbytes / dbenv->mp_ncache) * GIGABYTE;
- reg_size += ((roff_t)(dbenv->mp_gbytes %
- dbenv->mp_ncache) * GIGABYTE) / dbenv->mp_ncache;
+ reg_size = GIGABYTE / dbenv->mp_ncache * dbenv->mp_gbytes;
reg_size += dbenv->mp_bytes / dbenv->mp_ncache;
*reg_sizep = reg_size;
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 7 months
Re: ITS#4703 mirrormode hole
by Aaron Richton
> While we're at it, we should add a consumer option for specifying
> additional locations in which to store contextCSNs. This would e.g.
> solve ITS#4626 by allowing a consumer in a glued subordinate to keep its
> parent context up to date.
One thing we've been kicking around lately was a dream-list feature of
"throw a contextcsn on any arbitrary entry." Our motivating problem was
essentially
+ dc=syncproved,dc=rutgers,dc=edu
+ ou=Boot-Time Configuration
+ ou=Dynamic Configuration
We wanted the ability to arbitrarily add a contextcsn attribute into
"ou=Boot-Time Configuration,dc=syncproved,dc=rutgers,dc=edu" despite the
fact that the suffix/syncprov was on "dc=syncproved,dc=rutgers,dc=edu".
This would be combined with, essentially,
/* if bootconfig is fresher than we are, reboot to get it */
if (contextcsn(BootConfig) > (``date`-/proc/uptime`)) restart;
to get things that can only be configured at boot time.
(No, we're not actualy that crazy with our systems, it's just a daemon;
but you get the idea.)
In the end, we're just searching for entryCSN>=lastRestart with base of
ou=Boot-Time. But contextCSN seems more eloquent (only pick up one
entry) and this might be (roughly) in line with what you were considering,
or give you some ideas (ridiculous though they might be).
16 years, 7 months
Re: commit: ldap/servers/slapd passwd.c
by Pierangelo Masarati
ando(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
>
> Modified Files:
> Tag: OPENLDAP_REL_ENG_2_3
> passwd.c 1.95.2.19 -> 1.95.2.20
>
> Log Message:
> complete fix to ITS#4665
>
Note: what we usually do is append modifications to the end of the
orm_modlist, so that they get freed along with the others by the
caller. In this case, a modification must go first. As a consequence,
it wouldn't be freed really. A cleaner approach would be to register
another callback that does cleanup of this modification __after__ it's
been used. I guess the current approach is just fine, although a bit
involved.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 7 months
manpages in HEAD
by Howard Chu
The manpages now source a shared file "../Project". Nothing in the
makefiles installs this file, so the Acknowledgements sections of each
manpage is empty. This shared file seems to need some re-thinking.
Nobody is going to want some generically file named "Project" installed
into their /usr/man (or whatever) hierarchy.
Perhaps it should be man8/ldap_misc.8 or something, so that at least it
has an identifiable name and isn't in the .../man directory.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 7 months
OpenLdap & Oracle/XE and threadless stub patch
by R.K. Owen
I'm trying to use the Oracle10/XE as a backend for the OpenLDAP
server, using the back_sql module.
I know that the unixodbc interface is working with Oracle because I
can access the database with the isql tool and view the test tables.
However, when I try to run the slapd daemon I get the following error
slapd -d 1
...
==>backsql_get_db_conn()
==>backsql_open_db_conn(4294967295)
backsql_open_db_conn(4294967295): SQLConnect() to database "OracleODBC" failed.
Return code: -1
nativeErrCode=0 SQLengineState=IM003[iODBC][Driver
Manager]Specified driver could not be loaded msg="[iODBC][Driver
Manager]Specified driver could not be loaded"
nativeErrCode=0 SQLengineState=00000[iODBC][Driver
Manager]/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1:
undefined symbol: bcuMsgBoxError msg="[iODBC][Driver
Manager]/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1:
undefined symbol: bcuMsgBoxError"
backsql_get_db_conn(): could not get connection handle -- returning NULL
backsql_db_open(): connection failed, exiting
backend_startup_one: bi_db_open failed! (1)
slapd shutdown: initiated
I haven't found where the bcuMsgBoxError symbol is defined (but it
shouldn't be needed since /usr/bin/isql works just fine).
Anyways, I thought I'd try configuring the anon-CVS source --without-threads
and found that the thr_stubs.c needed a do-nothing function to satisfy
the references below ... hence the attached patch.
connection.o: In function
`connection_operation':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1044:
undefined reference to `ldap_pvt_thread_pool_tid'
connection.o: In function
`connection_fake_init':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1955:
undefined reference to `ldap_pvt_thread_pool_tid'
However, any insight on resolving the bcuMsgBoxError problem and
getting Oracle to work as the back-end would be greatly appreciated.
BTW - I'm using Ubuntu 6.05 Linux.
Thanks,
R.K.
R.K.Owen,PhD rk(a)owen.sj.ca.us
LBNL/NERSC rkowen(a)nersc.gov
Univ. of California, Berkeley Wrk:(510)486-7556
16 years, 7 months
HEAD and connection speed
by Quanah Gibson-Mount
I've been twiddling around with HEAD, since it supports BDB 4.5 and OL 2.3
doesn't, and noticed that when I do speed tests, HEAD is 66% slower than
2.3 (+ my patches from HEAD for connections). This seems interesting to
me, since my connection code is largely from HEAD. In 2.3, I get 15,000+
auths/second on my 64 bit test systems, but with straight HEAD code, I only
get 5,000 auths/second.
In both cases, the lightweight dispatcher code is enabled. Any thoughts on
what else may be affecting HEAD? The configuration is very simple, just a
small 250k bdb database.
--Quanah
--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
16 years, 7 months
Special identities and connections in proxy backends
by Pierangelo Masarati
There might have been some confusion recently and not so far in the mind
of at least one of the developers of the proxy backends (me).
Especially back-ldap allows few slecial identities to be configured,
which may serve some of the special purposes this backend is required to
implement.
One of them is the "acl-bind" identity (see slapd-ldap(5)), which is
used for operations that are privileged, meaning internal operations
used by special internal features, or operations performed using the
rootdn identity. If this is enabled, and an operation occurs on a
connection that's authenticated as the rootdn of the database (either
because this is true, or because it is pretended by the code that called
that operation of back-ldap), binding to the remote server occurs with
the identity specified in the "acl-bind" statement, either using SASL or
simple bind.
Another one is the "idassert-bind" identity. This is used, if
configured, whenever an authenticated connection tries to perform an
operation thru back-ldap (this was recently added to back-meta as well)
and that back-ldap database is not the authorizing database for the
connection, and thus there is no other means to inform the remote server
that the connection is authenticated.
Privileged connections get cached. Connections used for idassert should
be cached as well, as they always use the same identity, and typically
assert that of the client by way of the proxyAuthz control. The latter
didn't quite happen until a recent fix, though.
The point is that there used to be (and there is, I haven't committed
recent fixes yet, since I'm trying to convince myself that everything is
now fixed :) some confusion about those special identities. What I came
out so far is that in the internal handling of those special connections:
1) privileged connections are treated some way
2) idassert connections are treated separately
3) in case a connection ought to be privileged, but acl-bind is not set
and idassert-bind is set, the latter identity is used for privileged
connections as well
I'm not 100% convinced about (3), though, because that would obfuscate
what identity is used for what purpose. The reason for (3) is that if
one doesn't need to have privileged connections, he shouldn't set
acl-bind at all; however, there might be cases where one wants to have
identity assertion in place, and if acl-bind is not configured,
connections as the rootdn wouldn't exploit it (this may happen, for
example, when using slapo-chain(5) on top of a database that needs to
have the rootdn in place).
So the point is: is it preferable to explicitly configure twice the same
identity, or have a "sane" default if one only sets idassert-bind and
not acl-bind? All in all, the identity that's used for identity
assertion is not likely to be more privileged than the privileged one...
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 7 months
Syncrepl client API
by Pierangelo Masarati
I've implemented a client API for the LDAP Content Synchronization
operation (RFC4533) which basically provides a clean and simple
interface to using the operation to sync client's data based on the
status of the producer. This is not only intended to provide
replication capabilities, but also to implement client-side "persistent
search"-like feature based on stock slapd (>= 2.3), without the need to
revamp the persistent search IDs and code yet another overlay.
The API essentially consists in a data structure that contains data
required to initiate/re-initiate the search operation, to keep track of
the current state, plus a set of handlers that will be called based on
the event that occurs: when a search entry, a search reference, an
(already parsed) RFC4533 intermediate response or a search result done
message are received, respectively. This frees the client from knowing
any of the details of RFC4533, except for a loose knowledge of the type
of events that can occur.
Its usage is quite simple: set up the structure, including an already
initialized connection handler, call ldap_sync_init() specifying the
mode (refreshOnly, not implemented yet, or refreshAndPersist). When
using refreshOnly, that should be all; call ldap_sync_init repeatedly to
refresh. When using refreshAndPersist, repeated calls to
ldap_sync_poll(), with different timeout policies, are required to
inquire for further responses; the provider or the consumer could decide
to restart (or connection to the producer could be lost for some reason;
in that case, simply call ldap_sync_init() again. Details about setting
up the connection with appropriate data protection and authentication is
left to the client, as it's out of the scope of syncrepl.
I would like to add this to libldap, as the customer that requested its
implementation agreed in open sourcing it. I'll post an ITS about this
soon. In the meanwhile, I'd like to hear general comments about the
overall design.
One relevant point is that it strictly implements RFC4533, so delta
syncrepl has not been even considered, as there's no specs for that.
Initially, I thought a good place to test and use this API would have
been to replace the bundled syncrepl consumer code in slapd, but the
absence of delta syncrepl makes this option non feasible. This is a
pity, because having it there would have meant lots of bug tracking and
support from the community of syncrepl users.
Nonetheless, apart from my very limited knowledge of delta syncrepl
implementation details, I don't think adding it to this public API would
be a good idea, because it seems to imply a bit too much knowledge about
its implementation details, like the contents of the sync cookie, and
very precise and specific details about the implementation of the
changelog database. Either those details are coded in a document like
RFC4533 (and freeze), or I would leave that optimization to slapd's
internals.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 7 months
