svn commit: samba r12293 - in trunk/source/utils: .

[simo]

On sab, 2005-12-17 at 10:23 +0100, Volker Lendecke wrote:
> Internally we should work towards getting rid of names as much as possible,
> convert names to sids as early as possible. One reason I found is for example
> auth/auth_util.c:735. We take a decision where to look for additional groups
> based on the username, which is wrong. A customer of mine needs to use locally
> defined aliases on a member together with 'winbind use default domain'. No
> separator in the name, so nobody asks winbind to expand the aliases. No alias
> shows up in the token. Boom. If we had passed down a SID to this function then
> a sid_check_is_in_our_domain would have given the right answer.
> 
> That's why I want to see only one single use for lp_winbind_separator() for
> dissecting a name: In lookup_name. And that as early as possible in the game,
> when the name comes from the net. This also has the potential to make error
> checking more correct: In a routine close to the user we look up the name and
> expect a user. When it is something different or does not exist, we can
> probably return a more correct error message.
> 
> I also think this is a more correct way to attack the passdb mess we have than
> voyager was. Group mapping as it stands is broken, but completely replacing it
> is probably too radical. In particular changing all the LDAP databases around
> is not an option. But when we could really REMOVE pdb_getsampwnam(),
> pdb_getgrgid() and pdb_getgrgid() I think we could win a lot of clarity. Moving
> pdb_getsampwsid to a rid-based function is a little step. pdb_getgrsid and the
> alias handling functions need to stay sid-based, they also have to take care of
> S-1-5-32. But when we are more SID-based internally this becomes a lot more
> obvious than it is now.

I completely agree with you. The failed attempt of idmap (the part that
didn't survived) work initially done was to reach most of the objectives
stated here, convert once and in a central place to avoid mistakes and
help keeping the core of resolutions as early and as correct as
possible.

> This is a change in behaviour, and has the potential to break some
> installations. For example if both a group "foo" and a user "foo" does exist in
> Unix, in routines where we *know* the name should represent a group (callers of
> nametogid() for example) would break. I'm not sure how to handle that case in a
> sane way. But I do think it is necessary to really straighten our name<->sid
> mapping towards what Windows does, this has led to way too much confusion and
> bugs in the past.

Agreed, the current situation can be enhanced a lot by your proposal,
better to break a few installations but have a better resolution
mechanism, that will pay in the long term imho.

Simo.