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 the world.
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...
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 the world.
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...
-
Howard Chu -
Marcel Wysocki