[Date Prev][Date Next]
Re: slapd as an appliance
Sounds like you want to port slapd to OSv ( http://www.osv.io ) ...
because... who needs linux anyway ? :p
On 10/28/2014 05:14 PM, Howard Chu wrote:
A couple different random thoughts all collided so I thought I'd jot
them down here...
We can have back-mdb/LMDB set the PROT_EXEC permission on the mmap,
and then store executable code in LDAP entries and execute them
directly. The idea came to me while reading about just-in-time C
compilers and remembering my previous plans for liblforth. At first I
was thinking only of small plugins (e.g. syntax parsers/normalizers)
but really there's no reason that you couldn't handle larger
executables the same way.
I.e., we could store all of slapd's dynamically loadable modules in a
back-mdb backend, change olcModuleLoad to use a DN, and dynamically
insert and delete code on the fly, without needing any filesystem
interactions. Once you have a system where all administrative
operations can be done through LDAP, without requiring any other admin
interface, it becomes pretty trivial to drop it into a sealed black
box and deploy an "appliance." This would be a pretty key advantage
for a small, self-contained embedded processor.
Of course, it doesn't stop there - if the only system interface needed
is the LDAP port, we don't even need a full OS distro any more. We
could run slapd as process #1 (who needs systemd?) - a hardened system
with zero unexpected attack surfaces, only one network port open to
One of the current in-progress items for LMDB is to enable using it on
raw disk partitions. Adding this feature would mean you no longer have
to worry about what type of filesystem to choose, or how to format it
before setting up a database. Again, it would be ideal for an
appliance because you'd just have to plugin a storage device and then
create a back-mdb backend pointing to it.
Another item for LMDB, once raw partition support is working, is
in-kernel LMDB. Initially my motivation was to reproduce the KBDBFS
work - an in-kernel filesystem built on top of BerkeleyDB (see here
http://www.fsl.cs.sunysb.edu/docs/kbdbfs-msthesis/ ) but there's no
need to stop there. We could port all of slapd into the kernel, and
have a turnkey appliance with no user processes at all.
Food for thought...