[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
