Gerald Carter wrote: > > On Wed, 2 Oct 2002, Andrew Bartlett wrote: > > > The access checking is done by the SAM module. The reason it is not > > done 'above' the interface is to ensure a 'choke point'. I put a lot of > > effort into the auth subsystem to ensure we never 'accidentally' forgot > > to check for null passwords, missed a restriction etc. I intend the SAM > > to be written with the same caution. > > This seems like a lot of duplication of code and can lead to > "There's a bug in SAM1 but not SAM2". If the access checks > will always be the same, why push them into the SAM module and > force each write to cut-n-paste security descriptor code.
Yes, I am worried about that a bit. The main issue is that I would like a single read from LDAP - so we don't get a race there. But we could do it 'after the fact', and get each module to pass up the security descriptor to the SAM interface layer. > > The reason the access checking is not handled by the interface itself is > > due to the different implementations it make take on. For example, on > > ADS, you cannot set a password over a non-SSL connection. Other > > backends may have similar requirements - we need to leave this policy up > > to the modules. They will naturally have access to 'helper' procedures > > and good examples to avoid mishaps. > > This still doesn't make sense. The SSL requirement is separate from the > security descriptor check (if that is really what you are talking of > using). Push the sec_desc check above the SAM and just let the > SAM module fail if it has extra requirements. Group common code together. Yes, it could well belong in the interface layer. > > (Furthermore, some backends my actually chose to push the whole ACL > > issue to the remote server, and - assuming ldap for this example - bind > > as the user directly) > > I see this but I think it tends to muddy the water a little. > What exactly are you calling a SAM? > > > Each returned handle has an internal 'access permitted', which allows > > the 'get' and 'set' routines to return 'ACCESS_DENIED' for things that > > were not able to be retrieved from the backend. This removes the need > > to specify the NT_TOKEN on every operation, and allows for 'object not > > present' to be easily distinguished from 'access denied'. > > > > When you 'set' an object (calling sam_update_account) the internal > > details are again used. Each change that has been made to the object > > has been flagged, so as to avoid race conditions (on unmodified > > components) and to avoid violating any extra ACL requirements on the > > actual data store (like the LDAP server). > > > > Finally, we have generic get_sec_desc() and set_sec_desc() routines to > > allow external ACL manipulation. These do lookups based on SID. > > So a SAM is a passdb with ACL's. What else? Groups and policies thown in, but it's not really meant to be that massive. One step at a time and such things. Also a move to NTTIME in the interfaces, and an attempt to cope with a wider scope of problems. Mostly it's a rework so we could move further forward then passdb could reasonably be streached. It sounds big, but it really isn't... 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