Elrond Elrond at
Thu Feb 24 18:44:29 GMT 2000

On Thu, Feb 24, 2000 at 10:32:13PM +1100, Michael Stockman wrote:
> 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.

I'll write something about that in another mail.

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

Sounds interesting, but I think, we shouldn't do this

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

Ahh... Okay. Nice idea...
So when you create NT-SDs back from this, you've got to
sort the dacl-entries into NT-dacl and NT-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.

So sacl is more like "admin-acl" ?

Two things:

What does happen to the ACEs in this acl, when you map to
(In fact, you created something, that most ACLs don't
 have... so we now have a superset)

... I still have to think, wether I like it, or not... Most
admins (not the good ones) have problems with those things
and end up doing bad things... and I like the user having
full control of the acl.

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

I think, it is quite "written in stone". But if you like,
you could all it do a default racl.

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

Ahh... That sounds reasonable.

Luke: Your current se_access_check does need the
permissions to be granted always completely...

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

WRITE_DAC is on Unix only allowed to the owner of the
object and to root.

READ_CONTROL is a bit different on unix... your partly

You need to have +x on _all_ directories, that lead up to
the object of interest to be able to do a stat() on it. You
do not need any permissions on the object itself.

This would mean, you would map AND(x-bits of all parent
dirs) to READ_CONTROL of the object, but that's wrong:

NT has also the right to disallow you to get into a
directory, and all its subdirectories. It's just, that in
the standard-NT-install there's an "Overwrite
directory-traversal check" in the "System Policy" (look in

So that should be properly mapped there, no need to map
this into the file.

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

Yes, the read-function may do that.

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

That's from:
  Subject: Re: NT ACL / Security descriptor checking function
  Date:   Sat, 12 Feb 2000 03:30:56 +1100


More information about the samba-technical mailing list