Samba under Coherant and Macintosh

[Luke Kenneth Casson Leighton]

On Sun, 19 Dec 1999, Jean Francois Micouleau wrote:

> 
> On Mon, 20 Dec 1999, Luke Kenneth Casson Leighton wrote:
> 
> > it's going to be a lot of work.  there are well over a hundred locations
> > where this function needs to be called, so i hope to automate the process
> > somehow.
> 
> 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.

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

assuming that it doesn't result in zero bits set, you can then check the
remaining permissions against the type of Open call, and then return a
handle associated with the permissions allowed.

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


unfortunately, it's just not enough to check at the "open handle"
functions.

and functions such as NetServerGetInfo don't have handles associated with
them [only auto-handles, in the dce/rpc implementation, i think].


> remember we (you, jeremy and I) discussed that point several months ago in
> private in the case of the spoolss pipe. The conclusion was to not do
> anything and use the unix security, and that we need a more complete user
> struct.

yes.

andrew doesn't want to use unix security.

> > there are cases for levels at 0-10, 10X, 40X, 50X and 100X that need to be
> > examined in the MSDN to confirm this empirical observation.
> 
> levels are pipe dependant.

the numerical info level itself?  i still think it's worthwhile doing this
analysis, and it may turn out that the relationship between the numerical
info level number and the kind of access rights we can associate with it
may vary on a per-pipe basis, however that would complicate matters for
microsoft, so i don't see why they would have wanted to do that...
deliberately :-)

there's always room for accidental design, especially in microsoft's book.
we tried asking them for SMB docs three years ago, they said there weren't
any, that's what the cifs initiative was about.

[let's hope they haven't done the same thing for nt5...]

luke