ACL / SDs

[Michael Stockman]

Hello,

First, the order of ACEs in an ACL is important (at least for access
checking). This is how it works on NT, and AFAIK everywhere else.

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

Yes, NT has it (and doesn't use it). We have it and doesn't use it as
well as we have and doesn't use audit. When someone think of a good
way to implement it (for example a DEBUG statement for audit) then we
have and use 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.

I know this is how NT does it. I'm not sure this is how we want it. I
could imagine that some scheme where a user can audit his own objects
(with audit ACEs in a dacl) can be useful. Also I could imagine the
admin to want to be able to restrict user(s) ability to change (some)
permission(s) on some object(s), with access permissions in the sacl.

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

This is how it works, and that is why the order is racl, sacl, dacl.
The intent is that racl should be controlled at server level (not
saved with the object) and should override anything a user may set in
their ACLs, thus it is evaluated first.
The system ACL is evaluated then. It's a design question if you want
to allow administrators to make ACLs with higher priority than the
user's ACL. I think the question can also be put like, who do you
trust the most, the user or the administrator?
Last the dacl is evaluated.

> 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
> inheritance)

There is, both owner and primary group. I don't know if the owner's
ability to change the dacl is so written in stone that we should force
it in the code, or if it should be enabled by any of the ACLs.

> > For access to be granted, any of the ACLs must grant
> > complete access.
>
> Do you mean a single ACE must grant the complete access?
>
> So:
> 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.

No.

I mean that if the racl allows 0x1000 and the dacl allows 0x0001 you
will get access denied. NT doesn't have this problem. If several ACEs
within one ACL together allows a set of permissions, access is
granted.

> [...]
> > 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?

Yes, and perhaps READ_CONTROL and WRITE_DAC?

> IMO you shouldn't change this one in write_SD.

No, I don't think you should too (in cases where the permission is
part of the directory's permissions). However I think the read
function should try to find out.

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

It might have been in a part that I haven't read yet. I'll get to it
and take it up for discussion (if I don't think it is absolutely
obvious that it should work a certain way then).

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se