NT ACL / Security descriptor checking function

[Luke Kenneth Casson Leighton]

On Fri, 11 Feb 2000, Michael Stockman wrote:

> Hello,
> 
> > well, i mentioned that we needed this function about four, six and
> twelve
> > months ago.  no response.
> 
> You frequently fail to fit your explanations into a proper structure.

*sigh*.  i know.  by the way, i apologise for the original message, i had
been going 18 hours straight by that point and consequently feeling ...
less inclined to diplomacy.

the public mailing list equivalent of a 3am letter :)

yes, i know i have difficulties puttting things into context, i also don't
really know what form i'm _supposed_ to put them in, so i make do.

> > now, i take it, that people are starting to realise _why_ it's
> needed.
> > so, if someone implements it, i'll use it.
> >
> > deal?
> 
> I still think the concept of ACLs haven't been covered completely yet,
> but maybe the basic structure is clear enough to make something to
> look at (I reserve the right to continue discussion).

:) oh good.

well, the basic function is that security-check one that takes
user-context, permissions-being-requested and security descriptor.  that's
not going to change.

> > security descriptor code is in rpc_parse/parse_sec.c.  please do not
> > modify this code, use it.  add your own wrappers if necessary.
> 
> Unless it has changed in TNG (which I will not download), I would
> suggest not using it but trying to read it and create a proper
> implementation (the one in head isn't pretty).

neither is the one in tng.  the code has to be capable of both marshalling
_and_ unmarshalling.  actually, you don't have to do it that way, you
could write two separate functions.

the format of an SD is fortunately pre-defined.  there is also a
pre-existing API for creating SDs and their sub-components: microsoft
MSDN.

entirely up to the implementer to come up with something.


> > you should reference the MSDN for the exact function parameters and
> name
> > of the function.  it will be something like this:
> >
> > check_access(NET_USER_INFO_3 *user_info, uint32 access_rights,
> > SEC_DESC_BUF *security_descriptor).
> >
> > user_info contains the user RID, primary group RID and
> > array-of-group-member-RIDs.
> 
> Is RID really the way to go???

if you're asking me?  yes.  anything else has to be either a superset or a
re-invention of the pre-existing scheme with which [i?  we?] are
ultimately aiming to be compatible.


> Access checks in samba has so far been
> POSIX, RID would break this (and create vast amounts of headache when
> samba can properly understand the difference between local accounts
> and remote accounts, unless RID means SID).

ah, yees: sorry, NET_USER_INFO_3 contains the user's RID, the domain SID
is implicitly tagged on the front.
 
> I think we should create our ACL implementation aiming on (future?)
> file support too (one ACL support for all ACLs) and thus have and
> internal POSIX based ACL which can map both UNIX ACLs and NT ACLs.

this was discussed four to five months ago, my recommendation was to do it
the other way round: map immediately out as soon as possible to NT
security descriptors, and maintain for as long as possible NT SDs before
converting to, say... POSIX or Unix ACls or file permissions.

reason: you don't want to impose a restriction, in the file-system
example, of mapping to POSIX-based ACLs, only to find later that the
underlying filesystem actually supports a much richer ACL implementation
thatn the [limited] POSIX one, or even fully supports NT security
descriptors, such as the linux NTFS drivers.