read/write idmapping in s4 rfc 2307 mode

[Gémes Géza]

2012-07-12 15:22 keltezéssel, Andrew Bartlett írta:
> On Thu, 2012-07-12 at 15:14 +0200, Michael Adam wrote:
>> Andrew Bartlett wrote:
>>> Gémes,
>>>
>>> Indeed, this is exactly the purpose for which this was implemented.  I'm
>>> glad you find it useful!
>> If I read the code correctly, the s4-idmap code only reads the
>> rfc 2307 attributest but does not write to them. New mappings are
>> created in the idmap.ldb always.
>>
>> This is confusing.
> It is, but we operate under some limitations and this was as much as I
> felt I could safely enable.
>
>> Shouldn't we add a mode where new mappings are also created in
>> the sam's posix attributes if the "use rfc" is on?
> The issue is distributed/atomic uid allocation across the domain.  At
> the moment, the RID is the only thing that gains these properties.  This
> could be combined with trustPosixOffset once we both implement that (the
> PDC emulator needs to recognise an incoming trust without one of these,
> and add the offset attribute)
>
> I'm also discussing with Gémes about the
> msSFU30MaxUidNumber/msSFU30MaxGidNumber attributes in the 'Re: Samba4
> patch for manipulating Unix attributes via ADUC' thread.  These
> attributes are enticing, but without atomic allocation, there is an
> inherit race condition.
>
> Finally, if we allocate these for users that are not subject to upgrade,
> we have the issue that we cannot issue IDMAP_BOTH mappings via the
> standard schema, and so groups created with these id mappings cannot own
> files.
>
> As always with idmap, there are many problems, and only a few, partial
> solutions.
>
> Thanks,
>
> Andrew Bartlett
A quick and dirty solution to the problem would be to use the RID as the 
uidnumber/gidnumber on allocation, that way it is going to be unique 
across the domain (in the forest it is another story), plus each group 
could get an uidnumber (via idmap) as well.

Cheers

Geza Gemes