[PATCH] New external idmap module

[simo]

Recently I have been involved in making it easier to provide custom id
mapping for samba. In some situations it is preferable to do the mapping
from outside samba to keep control on what get mapped.

One of the goals was also to make it easier to provide such mapping
without the need to change the source and keep it in sync at each new
samba version.

The idmap interface has not changed much if at all since we introduced
it in 3.0 and I do not see it changing much in future, so I decided to
make a module that forwards mapping calls to an external daemon using
either a unix socket or eventually a tcp socket.

Actually I tested only the unix socket, but I added the tcp transport
too because I think it is a great idea to be able to use this module to
keep multiple samba server in sync without requiring to set up an ldap
server just to keep the shared map. (The tcp socket may also help the
architectures that does not have a viable unix socket facility if any).

This is the smb.conf syntax to use this module:

idmap_backend = external:<local|remote>:<unix|tcp>:<path|address>

1) Define whether it is a local or a remote store

You must be careful with this parameter, usually you will want to
declare the external store as "remote", this will let samba use
idmap_tdb to keep a local fixed cache, this also means that if your
daemon dies, samba will be able to solve all the mapping that are
already in the cache and you will loose only the capability to store new
mappings.

Anyway in some cases you may want total control of the cache too, to be
able to change mappings without the need to wipe out the tdb cache, you
will just need to reconnect and spawn a new smbd process to see the new
mappings, in this case you may declare the module as "local" and it will
take the place of the idmap_tdb cache.

2) Select the desired transport.

I advice you to use "unix" against "tcp", the tcp transport actually has
no authentication mechanisms so you must use special care when using it
(I advice to use stunnel if you need to use it between 2 machines, so
that the communication is sealed and x509 certificates can be used for
mutual authentication).
The unix socket on the other side can rely on file system permissions
and I strongly advice to keep the socket readable and writable by root
only.

3) either the path of the unix socket (remember that unix socket paths
cannot exceed 108 characters), or the tcp address in the form:
a.b.c.d:port

Jerry,
if there are no objections I would like to commit this code into trunk
and see it in 3.0.24, I think it will be of great use for many people
that want better control on their mappings without being constrained by
the current available modules. The communication mechanism (described in
the module source code) is really simple and can be easily implemented.
The example daemon uses an sqlite3 database to keep the maps just to
show how it is easy to use alternative methods.

If there is real interest in the tcp support, let me know so that I can
dedicate some energy in enhancing it.

Have fun,
Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samba3_idmap_external.patch
Type: text/x-patch
Size: 43952 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060530/3d0b4068/samba3_idmap_external.bin