[PATCH] idmap-plugin for static rid->[u|g]id-mapping

[Simo Sorce]

On Thu, 2004-03-25 at 20:58, Guenther Deschner wrote:
> Hello Simo,
> 
> 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.
> 
> Thank you. 

Sorry about that, but that's what it is.

> > 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.

Mainly security or accessibility problems, unless the ACL translation
code is aware of the fact uids may in facts represent gids ...
Anyway you get unconsistent access through the unix filesystem (read
NFS) or through samba.

> > 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.

That's unacceptable in many cases, and makes things too complex for the
average administrator.

> Sorry, forgot to mention: Of course your
> domain-ranges *have* to be wide enough to map all required rids.

They simply can't RIDs are 32bit values, a Single domain may cover all
the uid space you have.

> Multi-domain-setups require a bit of preparation for the configuration, I
> admit. Currently out-of-range rids are simply not mapped.

You may accept the limitiation but is not an acceptable policy in the
general case.

> 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.

Ok, I'm fine you can provide the module with your distribution probably,
but I would not like to be in you support staff then :)

> > 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.

As I wrote that functions I know, but in that case you have a simply
Access Denyed. So that the suer will not be able to use the samba server
at all ... I'm not sure this is acceptable for most admins.

> > 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.

rsyncing an mmapped file with locks is not wise indeed, if rsync is your
preferred method you should make a tdbbackup copy before the rsync, but
that would be a problem on the receiving part anyway if the file is in
use.
Instead access to a tdb is already done simultaneously by the internal
code, that's why tdbs have byte lock range capabilities. If you want to
share a tdb through nfs or similar you only need to take care of not
mmapping it and be sure the locking is working correctly in your nfs
setup. At that point you can share the tdb.

>  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.

Yes, that's simpler in the short term, and that's why we used to have
the algorithmic mapping samba, and that's why it was single domain code
and we had to switch to allocated mappings for winbindd.

You're free to make whatever module you prefer but you should also think
of the consequences then.

If the problem is simply a common allocation mnechanism, then I think
that building a module that is capable of communication with other
similar ones is the right way. If you look at the RFCs repository you'll
find a proposed protocol to do that. It is proposed by someone (sorry
I'm offline right now and my memory is weak, so I do not remember the
name nor the RFC number) working for Sun and used to solve the same
problem with NFSv4.

Simo.

-- 
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l. - http://www.xsec.it
via Garofalo, 39 - 20133 - Milano
mobile: +39 329 328 7702
tel. +39 02 2953 4143 - fax: +39 02 700 442 399