Explaining the new SAM

Andrew Bartlett abartlet at samba.org
Wed Oct 2 02:22:01 GMT 2002

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

More information about the samba-technical mailing list