[PATCH] sam backend parameter

[Andrew Bartlett]

jra at dp.samba.org wrote:
> 
> On Thu, Oct 03, 2002 at 04:06:37PM +1000, Andrew Bartlett wrote:
> >
> > The use of multiple backends in passdb has acknowledged issues, and I'm
> > not particularly fussed if you feel it should not ship with this
> > functionality enabled.  However, please do note that this *is* being
> > used at present, and cannot be 'just removed'.  (We map our non-passdb
> > users into the system via this method).  Volker has some solutions to
> > this issue however, which look very neat.  I'll need to check if they
> > actually catch it all the cases.
> 
> Well it's not being used really, as it's not in a production
> release. We don't make guarentees until it gets into a production
> release. What "non-passdb" users are being mapped into the system
> via this method ?  Surely as a PDC we need passdb entries for every
> user we're exporting ?

I mean it's being used by code.

The problem is mainly on the fileserver:  For the DC side of things,
every user is in the SAM, or they can't really do much.  But on the
fileserver side, we have the problem that a user may select to view the
Owner or the ACL entries of a file.

This file may have a completely arbitrary owner.  

- Winbind user?  Fine.  (we simply lookup the uid->sid with wibnind, and
we simply proxy requests for the name->sid/sid->name to the DC)

- passdb user?  Again, OK.  
In 2.2, we just used an algorithmic mapping of all such users.  Remember
'2*uid+1000'?  :-)  Names were then looked up in the system get{pw,gr}*
calls

In HEAD, we tried to make this a bit smarter.  This may or may not have
been a good thing, because it can be slow.  We do getpwuid(uid), then
lookup that name in the passdb.  The returned SID is sent to the client.

For names, it's a bit easier, we lookup the SID in passdb then return
the name.  The reverse for name->sid.  I did it this way to allow for
arbitrary RIDs.

- not in either... Not so pretty:

The tricky bit is users not in passdb.  The code that deals with this is
hideous, particularly because we don't have a unified groupdb/passdb,
and mostly because I wanted to support arbitrary RIDs. (Hence one of the
reasons I started trying to rewrite this).  

We need to allocate this 'unknown' user or group a RID.  We need to
ensure it does not conflict with other users, and that it 'maps back'.  

Why?  Well, there are system accounts etc, and there are users who
appear in the system via NIS etc.  The 2.2 code maps these to
SIDs/Names, and I took this as a requirement that we must do the same in
3.0

The addition of 'unixsam' was designed to put common code together. 
Other parts of passdb had to deal with making a SAM entry from a passwd
struct, so I merged the code.  I had considered a complete merge with
smbpasswd, but never got that far.  Volker has noted a number of areas
in the auth code that could be simplified by exploiting this.

This also assisted in moving our calls to Get_Pwnam() into a very small
number of places.  It is very rarely called now.

If required, this code could be split back out again, however we still
have the issue of RID allocation.  (the cascading change did not affect
this, it is noted for completeness).  

The rids in HEAD are allocated by '2*uid+lp_algorithmic_rid_base()', to
allow the administrator to 'push' the algorithmic space 'out of the
way'.  We should look into 'automatic' RID allocation, but I am wary of
inflicting this on all our file-server users.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net