generic ACL interface (RFC)

[Cole, Timothy D.]

> -----Original Message-----
> From:	Luke Kenneth Casson Leighton [SMTP:lkcl at switchboard.net]
> Sent:	Tuesday, July 27, 1999 18:14
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	Re: generic ACL interface (RFC)
> 
> tim,
> 
> i would like to use the same acl interface on "objects" such as pipes,
> smbtrans2 requests, individual msrpc calls and even info levels within
> smbtrans2 or msrpc calls etc as _well_ as files / directories.
> 
	Ahh... good point.

> i would like to create static (or even dynamic) ACL objects that i can
> reference using a function, to check whether (for example) a user has
> sufficient access rights to enumerate a registry key; delete a user from
> the SAM database; do a NetShareEnum at info level 102 etc.
> 
> this is one of the "other" reasons for keeping the ACL interface, at the
> top level as "NT-like" (actually, "VMS-like" :-) as possible.
> 
	Ennhh... I still don't quite see the need to keep anything but the
general data representation the same.  but anyway...

> plus, we already _have_ code in samba that creates / decodes NT security
> descriptors (see rpc_parse/parse_sec.c): that's half the battle won
> already. all we really need to add is:
> 
	Yes, I didn't plan on writing new mapping code; I was assuming I
could take advantage of what's already used in nttrans.c's set_sec_desc and
friends.

> BOOL check_security_access(
> security_context, /* the SID of the user / process requesting access */
> access_rights, /* the access rights (read, enum, write etc) requested */
> security_descriptor); /* the list of rights for the action requested */
> 
> ACL-instance-implementations (e.g the file / directory one) *may* require
> knowledge of unix, but this should not be expected.  for example, what
> happens when we implement "appliance mode" fully, and someone installs
> this on linux with ntfs-driver support?  the fact that linux is unix then
> becomes completely irrelevant at that point!
> 
> so, the API you have started is useful - for a specific purpose.  that
> specific purpose is as a unix-ACL-file-sytem-support "sub" API.
> 
	Yes, that's primarily the angle I was looking at it from, although
the presence of SIDs in the structure was a hack taking into account the
NTFS thing you mentioned before.  (i.e. when you got the ACL back from the
function, flags would indicate whether the uid or SID or both were valid, to
allow for the underlying system only knowing/caring about SIDs -- but in
retrospect, no sense mangling the ACEs like that, really)

	Okay, your suggested approach makes sense, I think...

> the "main" API call check_security_access would be used:
> 
> - NT file SMBs (which contain security descriptors)
> 
> * obtain file system security_descriptor
> * create access_rights depending on file SMB being requested (e.g for an
> SMBreadX we set bit SEC_RIGHTS_READ_CONTROL
> * obtain security context
> 
> call check_security_access(file_sys_sec_des, file_acc_rights, sec_ctx)
> 
> 
> implementation of "obtain file system security_descriptor":
> 
> - if ordinary unix ugo / rwx permissions in use, go through mapping
> function that turns these into a security descriptor
> 
> - if unix ACLs are in use, go through tim's ACL api to create security
> descriptor
> 
	I think the first two items probably should get lumped together, as
in many cases you'll need to fall back from the ACL code to the normal
triplet stuff anyway.  (i.e. when you encounter an NFS mounted filesystem
that doesn't do ACLs).

> - if linux ntfs driver in use, go direct to disk and read security
> descriptor straight off the platters.
> 
	Yes, an intermediate representation doesn't make too much sense
there when you've got the final form directly availible.

> implementation of "obtain security context":
> 
> - when user logged in, the "password database API" was checked.  maintain
> state information of "unix user" (uid / gid) associated with "equivalent
> NT user" (user SID / group SID).  from this association, grab the
> "equivalent NT SID" that represents the unix process.
> 
> 
> for MSRPC calls, call check_security_descriptor() from:
> 
> - security descriptor obtained on a per-msrpc-call table and also on a
> per-info-level call.
> 
> - access rights obtained depending on the msrpc call (e.g SamrDeleteAlias
> is SEC_RIGHTS_DELETE).
> 
> - obtain security_context in same was as for file system: user logs in on
> SMB level or MSRPC level, password database API is checked: at that time a
> unix user and "equivalent NT user" are associated with the pipe; SID is
> obtained from this.
> 
> 
> complaints likely to stem from "inefficiencies" due to use of NT API.
> well, i don't think there will be any.  remember, don't knock the NT
> security API _just_ because microsoft is using it!
> 
	I still think it's way too baroque for the capabilities it provides,
but maybe that's just me.  I don't think that in the end it produces
especially inefficient code (in some cases, I think some of the "shortcuts"
were intended for speed reasons), but just really horrid aesthetics, and it
is a pain to code with.  Nor does it matter who produces it; I've seen APIs
from other vendors that were just as bad or worse ... (actually, I can
probably think of a few examples in POSIX that I dislike about as much).

	Doesn't matter really, as far as the requirements for the NT ACL
implementation, you know more about the subject than I do, so I'm not really
in a position to argue.  :P