Explaining the new SAM

[Gerald Carter]

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.

> 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.

> (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?





cheers, jerry