Samba under Coherant and Macintosh

[Luke Kenneth Casson Leighton]

On 21 Dec 1999, Todd Sabin wrote:

> Luke Kenneth Casson Leighton <lkcl at samba.org> writes:
> > On Sun, 19 Dec 1999, Jean Francois Micouleau wrote:
> > > 
> > > I don't think so. You need only to check in the "open handle functions".
> > > NT will try the different info levels only if you allowed it to do so in
> > > the reply to the open handle function.
> > 
> > unfortunately not, jean-francois.  "open handle" functions are where it
> > starts.
> > 
> > SamrConnect("\\PDC", SEC_ACCESS_MAXIMUM_ALLOWED, &pSamHnd)
> > SamrOpenDomain(pSamHnd, S-1-5-32, SEC_ACCESS_READ_ONLY, &pDomHnd)
> > SamrOpenDomain(pSamHnd, S-1-5-32, SEC_ACCESS_MAX_ALLOWED, &pDomHnd2)
> > 
> > each open call is checked against the permissions requested and the user
> > security context.
> > 
> > the requested permissions are associated with the handle returned
> > (SEC_ACCESS_MAXIMUM_ALLOWED with pSamHnd) _if_ allowed.
> > 
> 
> MAXIMUM_ALLOWED is a bit special; instead of having that bit
> associated with your handle, you get whatever permission bits you're
> entitled to.

... which means that we need _another_ field associated with each "Open"
of permissions-related function, yes, i was trying to to have to think
about this too much.

 
> > in the case of the SamrOpenDomain, the permissions
> > SEC_ACCESS_MAXIMUM_ALLOWED are ANDed with the requested permissions (for
> > the first call, SEC_ACCESS_READ_ONLY) before proceeding.  this can result
> > in zero bits being set, therefore can result in an instant "access
> > denied".
> > 
> 
> I may be misunderstanding what you're saying here, but it sounds like
> you're saying that the SamrOpenDomain call is checking that the perms
> you're requesting for the pDomHnd is a subset of the ones you received
> in the SamrConnect call.

subset... subset...  i _think_ that's what i'm saying, although i'm fairly
certain that i've seen requests that circumvent this behaviour.

SamrConnect(0x00000020) followed by a SamrOpenDomain(something else).

oh i don't know: i don't want to think about it!!!

>  If so, that's not correct.  In general, the
> way these things work are that when you do some operation on a handle,
> there's a check for whether the handle has been granted the necessary
> permission(s) for that operation.  In the case of SamrOpenDomain, you
> need to have been granted the SAMR_OPEN_DOMAIN permission in your
> pSamHnd handle.  

ah.  makes sense.

> > _then_ you may receive calls such as SamrEnumDomUsers(&pDomHnd, ...)  and
> > for each type of call:
> > 
> > - read
> > 
> > - write
> > 
> > - enumerate
> > 
> > we need to creaate a security descriptor.  in the SamrEnumDomUsers
> > example, it would have an ACL entry:
> > 
> > "Everyone" is granted "SEC_ACCESS_ENUMERATE".
> > 
> > _except_ if we decide to implement "RestrictAnonymous", in which case this
> > changes to:
> > 
> > "Authenticated Users" is granted "SEC_ACCESS_ENUMERATE".
> > "Everyone" is denied access.
> > 
> > .. or something of the sort, in order to deny anonymous users the right
> > to enumerate domain users.
> > 
> 
> Note that on NT, the SD isn't associated with a call, per se.  There's
> actually an SD for each and every object in the SAM.  That includes
> the SAM itself, the Builtin and Account domains, and every alias,
> group, and user within them.  I don't think samba has a way of storing
> these currently, but you may want to allow for this in the future.

do i have any choice?

hmmm... objects sounds better....  and an "object" typically has a
"handle" associated with it...

hmmm...  i've been thinking of using "handles" in this fashion in the SMB
/ MSRPC pipe code, too...