ACL / SDs

[Luke Kenneth Casson Leighton]

> > grep */*.h NET_USER_INFO3.  shows it's in include/smb.h in
> user_struct and
> > in include/rpc_netlogon.h
> 
> It isn't there (in HEAD), wait and I'll do a cvs update ... no luck

that's correct.

> > surs_sid_to_unixid(&sid, SID_NAME_DOMGRP, &unixgroups[i]);
> > }
> >
> > _then_ do a setgroups(n_unixgroups, unixgroups);
> >
> > i think.
> 
> Why? If the SIDs are in the struct they sure haven't mysteriously
> materialized there, and then someone have already looked them up ...
> the looked up unix data is as good as the NT data, no gain to
> relookup. I still think they should be stored in the user_info struct.

funnily enough, i was thinking of this, too, just now.

it's a matter of which you want to do.

do you want: the PDC to tell you what groups the user is in?

do you want: the local unix system to tell you what groups the user is in?

if the PDC is in fact a samba server, and it created the groups from the
local unix system, and the two local unix systems use the same remote
unix-group-database, then what's the difference?

well, actually, there _is_ a difference, because both systmes *may* use a
different SURS table, that is configured for each local unix system.  what
hapopens is this:

user logs on.  PDC grabs unix groups (gid_t*).  convverts each gid_t to a
group RID with its *local* SURS table.

group RIDs are transferred from PDC in NET_USER_INFO_3 structure to local
system.  group_rids converted to gid_t with *its* local SURS table into
gid_t* groups relevant ONLY to that local unix system (hi jeremy, you
taught me this one :)

for those people who may be thinking, "eh???", here's the crunch: a) the
two local SURS tables *may* contain identical lookups b) this results in
both local unix systems following the posix convention of usnign the same
local uids and gids to give the impression that both systems have remote
groups, and the user on both systems sees a consistent user/group
view-thing.

you get the idea.

anyway, this is pretty off-topic for what you wanted to discuss, tim, i
should imagine.

> > or the user's group.  or group members.
> >
> > so, as an ACL writer, you don't need to worry about
> SEC_MAXIMUM_ALLOWED.
> > the ONLY person that has to worry about this is the person (or
> persons)
> > that implements SeAccessCheck.
> 
> Actually, I regard sd_check_access/acl_check_access as a part of a
> complete ACL/SD API so that would be me, unless someone else is also
> doing it. Well, I've already done it...sort of. Now I'm trying to
> figure out how the ACLs in a SD should work together.

great!
 
> > > objections to throwing them out of the internal access_mask and
> only
> > > having them in the NT access_mask?
> >
> > yes.  i told you, the minimum _and_ the maximum requirement is for
> full SD
> > support.  nothing more is necessary, and anything less will make it
> > unusable for generic support.
> 
> Well, even NT has banned them from ACLs. Don't let the fact that the
> code is the same in NT hide the fact that the bitmask in ACLs is a
> different bitmask from that by which you request a set of permissions.

... oh god.  well, that only makes the implementation of SeAccessCheck
complicated, nothing else.

ACLs and security descriptors are... pretty dumb.  you can put anything
you like in them, and this _can_ do a lot of damage, and it's totally your
own fault if you do this.
 
> > > Example of ACL, tell me what MAXIMUM ALLOWED should return (and
> why):
> > > ACE allows 0x7FFF
> > > ACE denies 0x0001
> > > ACE allows 0x8000
> > > These three ACEs apply to the user.
> >
> > MAXIMUM_ALLOWED is SeAccessCheck specific.  are you implementing
> this
> > function?
> 
> Yes. If you're correct then 0x7FFF is the right return value. Ok with
> me.

ok, then the ACL above is slightly nonsense, becaue i _think_ that the
forst ACE is encountered and the others, as a result, ignored.

urr... actually, that's not true.  i think the deny ACE is the one that is
ignored.  ur...

interesting exercise!

i _think_ that 0xffff _should_ be returned, but unfortunately, i bet yu
that 0xfffe is _actually_ returned.

request 0x8000.  falls through 1st and 2nd ace, hits 3rd, is granted.

request 0x0001.  hits 1st ace, is granted.  deny ace _should_ be first in
the list in this case, your ACL is an example of an ineffective ACL,
therefore.

request 0xffff.  hits 1st ace, is denied (too much).  hits 2nd ace, is
denied (0x0001).

hey, that's so cool!  it _is_ an effective acl, it's just not obvious
what's going in, and trying to create a MAXIMUM_ALLOWED is impossible :-)
:-)