[PATCH] New external idmap module

[simo]

On Wed, 2006-05-31 at 05:49 -0500, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Volker Lendecke wrote:
> 
> > What I fail to see in this whole thread is the reason why an
> > existing mapping needs to be changed. You need to change the
> > ownership of all files as well as all ACL entries in the
> > file system if you change an existing mapping. You could
> > play very nasty tricks remotely using remote set_secdesc on
> > files but this is putting the box into maintenance mode for
> > a while. The much easier way to do this is to remove the
> > cache completely and restart the box.
> > 
> > What scenarios do you have in mind that require changing
> > mappings?
> 
> On this point I will concede to Volker.  We need some specific
> examples of why this support would be appropriate in order to
> continue the discussion I think.

I see that changing a mapping is a problem, because often it means a
change in the ownership of some files, I am just trying to be pragmatic
and see that there are cases when a change is necessary.

This is a fact, and out of my control, from my POV I may not even care
why an admin may change the mapping.
If I am not in control of the mapping (as is the case when an external
authoritative mapping is used) then my only worry is to think what
happen if that changes and what is the best way to deal with the case.

What I see is that if you end up to need to do it and you have lots of
servers it becomes a bit unpractical to go on each server and delete the
winbindd_idmap.tdb file.
When you have hundreds of servers, that perhaps are not even under a
single administrator control, being able to push the change is ok imo.

2 scenarios I can see are:

1) Wrong setting: the admin assigned by mistake the wrong uid to a user
that collide with another, one of the 2 mappings need to change.

2) Migrations or incorporation: you acquire new servers from a different
management and find out that you really need to change around some user
IDs to let them join because some broken application depends on some
user uid to not change.
If you know what are the uid's you have to change, you can just do it,
and then connect only to the servers where the change uid user files
where hosted as an administrator and change the ACLs.

3) different admins: in many companies it may happen that different
branches have control on their own OU (ldap or AD) and can change their
data without the need to communicate it to someone else.
So if I have admin1 in OU1 that decides to change one mapping he may or
may not tell it to admin2 of OU2. What it is certain is that admin1 does
not have access to admin2 servers and can't decide when to stop the
other admin servers. Still Admin1 is authoritative for his mappings and
usually have an assigned a range of uids to play with.
In this case requiring to restart all 100 servers of each admin because
one admin made a mistake in assigning a single mapping (maybe just for a
day or 2) seem to be a bit too much in my opinion.

If the idmap_tdb cache is involved, detecting the change in a local
server daemon would require the daemon to keep a backup mapping and
track the mappings by constantly querying the central mapping store and
comparing the result, this would mean you hit the central mapping store
quite a lot just to make sure mappings have not changed. And when you
find something changed you will have to run a process that wipes the
winbindd_idmap.tdb file and restarts samba (would you really like to see
samba restart under you ?), or do an idmap restore on a live system
which is perfectly equivalent to not use idmap_tdb at all as you change
the mapping anyway just in a more complicated, error prone, non scalable
way.



Changing a mapping is nothing different than changing the UID/GID of a
local user. We allow that, I do not see why we can't allow the same on a
domain/forest scale.
Keep in mind that changing the uid in ldap means that locally the user
will have indeed a different UID (when I use nss_ldap) only the
winbindd_idmap.tdb cache will be out of sync, and you have inconsistent
results.
When the user connects he will have an NT token with assigned his SID
but also his new UID (as the user sid comes form the nss layer), but
when looking from windows you will have also the previous uid->sid
mapping in the cache and things get really weird (2 uids -> 1 sid).



Said that, if we still think that we must make actively difficult to fix
mappings, and require admins to get crazy, months after the forgotten
supposedly fixed error, to find out why one mapping does not really
match, all I need is to remove the local|remote option for the module
and make is_local() always return False.


I still think that being able to keep the module as a way to communicate
to local or remote mapping daemons without the overhead of launching a
script at each mapping request make sense (exp, as a way to make it easy
to keep a centralized store without the need to build up an ldap server
just for that purpose. Many users on the mailing list cry when they are
required to use ldap as it is a bit too difficult for many of them).

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org