A RID allocator and its consequences

[Andrew Bartlett]

Volker.Lendecke at SerNet.DE wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > OK, the really nasty bit about this is the implict mapping of existing
> > unix accounts to rids.  I went to a lot of effor to try and get rid of
> > it - but the best I could do was hide it under a pile of interfaces and
> > pretend it wasn't there ;-)
> >
> > If you use smbpasswd, naturally, you get 'algorithmic' rids.  Fine, you
> > probably won't be using smbpasswd for this game anyway.  The problem is
> > that any unix user must also have a RID.  This is becouse at any time, a
> > user might try and get the security descriptor of a file.
> 
> First of all: My patch is absolutely experimental stuff, not yet meant
> seriously.
> 
> The right way would have been to remove the group rid from
> SAM_ACCOUNT. But this would have changed the interface which I did not
> want to touch in the first rounnd.
> 
> smbpasswd is the one where we get algorithmic mapping. I would like to
> see the algorithms in pdb_smbpasswd if that is possible. Or share it
> with nisplus (I still have to look at that one.). This however means
> that pdb_smbpasswd needs some knowlege of groups to be able to at
> least hand out a group rid upon demand. Hmm. Where does that lead? ;-)

pdb_smbpasswd and pdb_unixsam both use the code in passdb.c
(pdb_fill_sam_pw()) to construct their SAM_ACCOUNT, and to do uid->sid
mapping.  In fact, becouse of this, smbpasswd already uses the gid code
to determine the primary group RID on the fly. 

Teaching the other backends to do the same - or deleting the primary
group sid is quite reasonable.

> > The next problem is that we don't like reusing RIDs - so if that rid was
> > ever available 'implicitly' then we should not use it.  Also, a user
> > 'upgraded' from /etc/passwd should keep the same RID.  This is the
> > reasoning for the crazy stuff in unixsam.  (I'm still undecided if it's
> > very neat or an ugly hack...).
> 
> What crazy stuff do you mean? unixsam_update_sam_account?

That certainly sounds familure.

> > However, there is an 'out'.  If you never specify 'unixsam', and always
> > import users, setting a rid when you add them (currently smbpasswd uses
> > the algorithm or their unixsam upgrade), then this will work.  But if
> > sombody asks for a security descriptor on a file, and we don't know the
> > mapping for that owner, then it will fail.  BTW, using 'hide unreadable'
> > counts as asking for the mapping, as I found out recently...
> 
> For non-smbpasswd backends can't we take the same route as with
> get_group_from_gid: Create pdb entries on the fly?

As long as we have never made an implicit mapping between that uid and
RID, then it's fine.  One of the ideas with the new SAM stuff is that we
always control this mapping - it's the autoalgoirthmic stuff that kills
us here...

The only other trick is 'outside modification'.  When people put this
stuff into LDAP, they often like to modify it directly.  This may be 'a
bad thing', but it's also somthing we must at least tolerate.  (I
certainly do it at my site).  Therefore having the max rid stuff in LDAP
might be benifitial.

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