[PATCH] idmap-plugin for static rid->[u|g]id-mapping
gd at suse.de
Thu Mar 25 19:58:48 GMT 2004
On Thu, Mar 25, 2004 at 03:41:21PM +0100, Simo Sorce wrote:
> I see many problems with this approach that is even worse then the
> original algorithmic mapping of samba.
> Mixing users and groups is a probelm with ACL of course and may led to
> other problems with auth code i think.
I did several tests with setting ACLs in a multidomain-setup and did not
succeed to produce any bad effects. What kind of problems with ACLs do you see
exactly ? I'll investigate possible auth-issues later.
> But moreover, starting from your example, what will you do with
> RID=100500 of domain A? 10000+100500 = 110500 quite out of the original
> domain space you assigned right?
It remains unmapped in that case. Sorry, forgot to mention: Of course your
domain-ranges *have* to be wide enough to map all required rids.
Multi-domain-setups require a bit of preparation for the configuration, I
admit. Currently out-of-range rids are simply not mapped.
I can understand your problem with this, I see it as well for multiple
domains - how to estimate the highest required range-end for a domain?
That's guess-work, in fact. It might be an option to do the following:
enforce single-domain-mode while using this module via not even loading
the module as long as lp_allow_trusted_domains is true.
> And waht will you do with RID= 10500 -> UID=20500 wasn't this the
> DomainB administrator UID? wow we are administrators now!
For a single domain-setup, or a multi-domain-setup where just one domain
that you would like to map ids for is configured, "hijacking" uids does
simply not happen. In a multidomain-setup hijacking simply does not work.
See the checks in rid_idmap_get_id_from_sid where we explicitly check that
ids are not beyond or below the configured range. I'm unsure about
rid_idmap_get_sid_from_id though. Will check that.
> And also remember that while mappings are assigned dinamically they are
> set in stone in the proper tdb, so that replicating that tdb is enough
> for an HA-cluster.
With rsyncing tdbs we really made bad experiences, and of course you
cannot access tdbs simultaniously. Having a virtual mapping, that has no
need for whatever-backend (and all its drawbacks), a mapping that is in
effect immediatly, is really the solution we are looking for.
Guenther Deschner gd at suse.de
SuSE Linux AG GnuPG: 8EE11688
Berliner Str. 27 phone: +49 (0) 30 / 430944778
D-13507 Berlin fax: +49 (0) 30 / 43732804
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20040325/767416fc/attachment.bin
More information about the samba-technical