Prevent winbind idmap corruption

[Michael Steffens]

Andrew Bartlett wrote:
> This looks like a good idea - getting this stuff right does matter...

Even more since this db is very hard to recover with Samba onboard
facilities...

> 
> I don't like the use of uid_t for gid_t, on the assumption that they
> must be the same...  I know it will never happen, but it just seems the
> wrong way to go about it.  As you assume an int32 below, then maybe make
> it an int32 in the paramaters.

The deallocate_id function was derived quite straightforward from
its allocate_id counterpart, using the same types. The use of types
is not nice, agreed.

> 
> However, why do we need to 'roll back' the High Water Mark at all?
> 
> Instead, I would avoid the extra operation (if something failed already,
> then don't risk that something else could fail too) and just leave that
> uid/gid 'dead'.

This is something I would like to avoid, as UIDs and GIDs from winbind's
pool are limited resources, and are consumed unattended on client demand.
Extending the pool after IDs have been allocated and are in use will
often be difficult. Extending upwards is possible (if IDs directly above
are otherwise unused), while extending downwards or shifting is *very*
hard.

So at least when the failure is caused by a temporary and relatively harmless
condition like a full filesystem, a client attempting to connect again and
again should not be able to eat IDs endlessly.

In case of more serious failures, like disk defects or TDB internal
corruption, automatic recovery is difficult anyway, with or without
rollback of HWMs. I think best would be to have winbind stop and complain
then.

But some of these conditions are hard to detect, as the tdb_store_* routines
return "IO error" also when being unable to extend the TDB file due to lack
of diskspace.

In any case, with serious idmap database damage, there is no way around
rebuilding the TDB. Either with potential data loss from a previous snapshot
backup, or without data loss from a log, like

   http://lists.samba.org/pipermail/samba-technical/2002-April/036378.html

But the latter one has not become very popular...

Michael