Broken idmap interface design

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Peach wrote:

> There's two cases for mapping from SIDs to UGIDs.
> 
> First case is where full SIDs are explicitly stored 
> in the directory or have a static partitioning (like
> Unix Users and Unix Groups). In this case, you don't
> need to be told what kind of ID the caller is looking
> for, because the SID is globally unique, and must only 
> map to one ID.

That is the idmap_ad case where it is easy for the idmap
backed to determine the SID type.

> Second case is where the SID is dynamically 
> generated from other information in the directory. In
> this case, knowing the type of ID in advance helps
> a lot and can prevent you generating bogus SIDs.
> 
> I take it that it is this second case that is problematic?

It is the fact that the *default* winbind setup (using
tdb, rid, or ldap) requires that the idmap child call
back into the winbindd parent to get the SID type so
it knows what to do.  This is a layering violation.

The caller asks the idmap backend to give it an id
but the backend the asks the caller to tell it
what type of SID it is.  If this is needed, then the type
simply must be specified as a parameter or else we
will be tracking deadlocks in every idmap backend
implementation we have.

The problem was that the design was built for a specific
case and not the general case and is therefore not sufficient.

>> Right now I'm going to do several things in order to get
>> the code to a release point.
>>
>> (a) Remove WINBINDD_SIDS_TO_XIDS from winbindd_nss.h to
>>    prevent us from having to support the broken call in
>>    future releases.  The existing idmap_methods API will
>>    not change but will become solely an internal interface
>>    used by winbindd.
>>
>> (b) Overload the id_map.xid.type to be specified by the caller
>>    and not filled by the idmap backend.
> 
> So existing idmap modules will need to be changed?

That's debatable.  Right now, I'm considering the cache that
would require no change the the idmap interface, just how it
is used.

An example mapping on SID to uid would be as so.  The
caller fills in these values:

	sid_copy( id.sid, sid_to_translate );
	id.xid.type = ID_TYPE_UID;

Then the backend only fills in the id.xid.id field if the SID
does in fact resolve to a uid.

In most cases I've considered for the caller already knows
the SID type so this is no additional burden.

This would be the bare minimum fix for 3.0.25.  3.0.26 would
change the idmap API but as there are no external consusmers
other than winbindd, this should be easy enough.




cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGJ6z3IR7qMdg1EfYRAnDRAJ97e6yw2P8fVn2hZeBI/NfKBZDhSgCdFBvG
hBevuH5gRTkSHR2Vw33ERBE=
=Qoho
-----END PGP SIGNATURE-----