Bug 8444 - idmap_autorid does not have allocation pool
Summary: idmap_autorid does not have allocation pool
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.6.0
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Blocks: 8595
  Show dependency treegraph
Reported: 2011-09-08 10:44 UTC by Christian Ambach
Modified: 2011-11-10 19:52 UTC (History)
3 users (show)

See Also:

Proposed patch (as in master) (2.87 KB, patch)
2011-09-08 10:45 UTC, Christian Ambach
no flags Details
Proposed patch (as in master) (11.45 KB, patch)
2011-10-24 15:08 UTC, Christian Ambach
obnox: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Ambach 2011-09-08 10:44:18 UTC
This blocks the creation of BUILTIN\Users and other internal groups when autorid is configured as default id mapping backend.

Hence privileges will not be assigned properly and users are in less groups than they should be.

To make autorid a "complete" default idmap backend, it needs to be able to hand out uid/gids for internal purposes
Comment 1 Christian Ambach 2011-09-08 10:45:53 UTC
Created attachment 6867 [details]
Proposed patch (as in master)
Comment 2 Michael Adam 2011-09-28 21:12:34 UTC
I am undecided about this patch:

It makes use of the fact that the rids usually start at 500
and hence there is in particular an unused 499 rids at the
beginning of the first range. This range is used for the
allocate_id() which is used in group mapping.

This seems hacky to me. Wouldn't it be conceptually cleaner
to a whole autorid range for the allocate_id allocation?
It might be rather unusual, but it might happen that
a lot of local groups are created on the member server e.g.
for access control. In large environments this could easily
be more than 500 groups. I don't know what is common usage
here. Might well be that it is more common to create these
access groups for file servers also on the DC, but at least
it would be possible to do it as local groups on the member.

Therefore I would prefer using a (the first?) sub-range
for the allocate_id function.

Volker, Metze, I would like to hear your opinion.

Thanks - Michael
Comment 3 Christian Ambach 2011-09-29 12:55:41 UTC
I will create a new patch that makes use of a complete range instead of trying to squeeze it into the lowest numbers.
Comment 4 Christian Ambach 2011-10-24 15:08:21 UTC
Created attachment 7025 [details]
Proposed patch (as in master)

new approach using a seperate range for the allocation uid/gids
Comment 5 Christian Ambach 2011-11-10 10:36:41 UTC

please pick for the next release
Comment 6 Karolin Seeger 2011-11-10 19:52:24 UTC
Pushed to v3-6-test.
Closing out bug report.