http://git.samba.org/?p=vl/samba.git/.git;a=shortlog;h=idmap

[Volker Lendecke]

Hi!

Please find a bugfix in $SUBJECT.

On Mon, Jul 21, 2008 at 03:45:13PM +0000, Simo wrote:
> Things I don't like or find controversial:
> - I'd like an explanation of the reasons this patch cut back on some
> options and functionality and not just the description of a new behavior
> (so that people can understand why and not just what).
> 
> - the interface to query multiple ids at the same time (exp. multiple
> SIDs to uid/gid) going away (I really do not like this one).

That code was not used so far. I understand it is
potentially very useful, but with the idmap cache in
gencache we can grant r/o-access to it from smbd directly.
So assuming a long positive idmap cache time (i.e. a week),
it should be much less of a problem.

And, we can for sure re-add the code again.

> - the patch is incompatible with 3.0.25 and 3.2.0 configurations not
> only at the smb.conf level

The incompatible change I see is the params argument to the
module init call and the cleanup of the idmap_domain
structure. I do think the idmap_domain structure was really
overloaded, the modules should not have to know if they are
default, readonly or initialized. If they have to know this,
they can put their stuff into the private_data pointer.

> - the patch allows only the default domain to be written to, as the
> allocator backend is not allowed a different range from the default
> backend, and uid2sid checks are bound to the id range anyway.

Yes, and this is a deliberate choice. Nobody I asked, and I
did ask quite a few people (except you obviously... ;-))
understood the interrelationship between the different
backend types, ranges, and so on. So I think a severe
simplification is really necessary, potentially sacrificing
some flexibility.

> Still I didn't want to loose the ability to allocate IDs both in the
> local domain and in any trusted domain that allowed our server to add id
> mappings, so domains were identified only by name and SID and uid ranges
> were only optional and used as filters (mainly for read-only domains).
> A scenario where this would be useful is a server joined to an AD domain
> using tdb (or a local ldap) for local mappings and with one of the
> trusted domains being a Samba domain that shared mappings via LDAP. In
> this scenario (with a single allocator) you want to allocate mappings on
> the ldap server so that ids are unique on all servers and yet save
> mappings both in the local tdb (for local mappings) and on the LDAP
> server when the mapping is about that trusted domain.

From my point of view this is a bit too much flexibility.
Forcing users to assign the same gid for BUILTIN\Users on
all hosts participating in the LDAP based idmap is something
I could find arguments for, given that the configuration
becomes a lot simpler and more predictable this way.

> - the 'default' parameter going away if my own domain is not what I want
> to be the default. If the samba server using idmap_rid is joined to a
> 'minor' domain in a forest or more complex setup and you want to keep
> one LDAP server with company-wide mappings (where most other trusted
> domains are stored), then you may want to have mappings, by default, to
> go on the LDAP server that is referenced by trusted domains
> configurations.

With the code I propose the backend configured with "idmap
backend" must be writable. You can easily then configure
"idmap config <mydomain> : backend = rid" where <mydomain>
is the domain you are joined to. Tested that.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20080729/d0a29be2/attachment.bin