At 23:21 02.10.2002 +1000, Andrew Bartlett wrote: >Gerald Carter wrote: > > > > On Wed, 2 Oct 2002, Andrew Bartlett wrote: > > > > > > 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. > > > > Ahhh....ok I see now. But it still seems like a lot of duplicated > > code. > >I'm starting to agree that putting it in the interface is a 'good >thing'. If the backend wants to double-check, then that's fine, but the >intereface should be handed back a sec desc to check itself. (A SAM >that really wants to get around this can return an allow-all sec desc if >it must...). This does make it harder for module writers to 'stuff up'.
what's about a BOOL flag in the SAM_METHODS struct : BOOL access_check_intern; if False the interface should handle the sec_check. if True the backend will handle it. And double access check isn't a good way! (we want to handle large domains, and for this we have to be as fast as possible) > > Taking another perspective, i'm still not convinced why a security > > descriptor on each SAM object is needed. What do we gain by it > > at the cost of added complexity? > >NT allows these to be set remotely on each SAM object. In particular >the 'user cannot change password' is implemented in terms of an NT ACL >on the user in the SAM. We didn't have to store a SEC_DESC on each entry. We can use a default, but we have to be able to store it on each entry if the admin changes it explicit on the entry. > > > > 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 > > > > By policies you mean "rights" like "backup files" ? > >Also 'max password age' etc. > > > > 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. > > > > What "wider scope of problems"? Without knowing what you are trying to > > address, it's pretty hard to comment. > >Mostly to cope with all the things that can be set over the SAMR pipe. >(most of which are above). I think we are also meddiling a little in >the LSA pipe too, which may or may not be a good thing... > >It may well make sense to store all the replication stuff in the same >backend, to avoid having to run muliple synronistation setups. (ie if >LDAP is doing all the SAM stuff, make it keep the LSA secrets too). I'm >still thinking on this stuff, but that's the kind of longer-term I'm >looking for. that would be fine:-) >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 metze ----------------------------------------------------------------------------- Stefan "metze" Metzmacher <[EMAIL PROTECTED]>
