Elrond Elrond at
Wed Feb 23 13:32:11 GMT 2000

On Wed, Feb 23, 2000 at 12:14:47PM +1100, Michael Stockman wrote:
> SDs:
> I'm working on it. Really, it's no big deal. The issue is to obtain
> the user's uid and gids, but I trust Luke have got them stored
> somewhere.
> typedef struct __sd
> {
>   uint32 flags;
>   id_entity owner;
>   id_entity group;
>   ACL *dacl;
>   ACL *sacl;
>   ACL *racl;
> } SD;
> The racl is intended to be the root (override) ACL. Since ACLs are
> only stored as pointers, it could be shared between all SDs in a
> module and defined in some config file.

(Didn't NT also have this unused Alarm-ACL-thingy? Okay,
it's not realy there, so no need to worry.)

> A trap is that NT apparently can set an ACL pointer to NULL and (with
> a flag set) consider it to be an all allowing ACL. I'm not happy with
> that (and will probably map it).
> The ACLs are evaluated in racl, sacl, dacl order.

sacl should only contain audit-acls, which are not used for
normal access-checks, but only for auditing. So sacl
shouldn't be avaluated normaly.

Further, if any ACE denies anything, that was requested,
the request should be blocked.

racl should be evaluated only, if dacl didn't already allow
access, so deny-ACEs can be overwritten. (This has also the
nice side-effect, that you could audit overwrites)

If you also want to be able to deny in the overwrite-acl,
you must have some "didn't find a matching ACE"-reply and
test racl first, and if "didn't find a matching ACE" is
returned, check dacl.

I also guess, you might need a special type in your
id_entity-type: "Current-Owner", cause NT has normaly the
overwrite, that the "current owner" can change the dacl.
(I don't know the precise relationship to "Creator-Owner"
in NT, but I guess, that one is only interesting for

> For access to be granted, any of the ACLs must grant
> complete access.

Do you mean a single ACE must grant the complete access?

ALLOW 0x1000
ALLOW 0x0001

and you request 0x1001, you get "access denied"?

I don't know, what nt does here, so I'm just throwing that
in for discussion.

> Also, some NT bits do in unix correspond to permissions of the
> container rather than to the object. Expect the read_acl / write_acl
> functions to require names of both the file file and the directory
> when the object is a file.

You mean the DELETE-attribute, which on unix is w on the
directory? IMO you shouldn't change this one in write_SD.

BTW: Isn't that covered in this big doc on converting
unix-perms to nt-sds? (Haven't read it)

> Read and write functions:
> I haven't started on those yet. They'll be my next task after the SDs
> (at least those that I can do).

You might want to look at this doc. the URL was mentioned
in this SD-discussion.


More information about the samba-technical mailing list