ACL / SDs

Michael Stockman pgmtekn-micke at algonet.se
Wed Feb 23 09:16:02 GMT 2000


Hello,

> > Yet again a status report. I have got ACLs running and seeming to
work
> > (except for maximum allowed). I'm currently doing SDs and would
really
> > like to know where I can find the NET_USER_INFO3 structure that
Luke
> > have written about.
>
> 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

> > SDs:
> > I'm working on it. Really, it's no big deal. The issue is to
obtain
>
> great.  see include/rpc_secdes.h
>
> > the user's uid and gids, but I trust Luke have got them stored
> > somewhere.
>
> yes.  user_struct.  the NT-equivalent info, minus the Domain SID
(because
> NET_USER_INFO3 only stores user_rid, group_rid, n_groups,
> member_group_rids*) is in NET_USER_INFO3 usr member of user_struct.
>
> the tricky bit is that strictly speaking we shouldn't be using the
local
> unix user groups but instead doing this:
>
> int n_unixgroups = user_info3.usr.n_groups;
> gid_t *unix_grous = malloc(n_unixgroups * sizeof(gid_t));
> for (i = -; i < n_unixgroups; i++)
> {
> DOM_SID sid = user_info3.domain_sid;
> sid_append_rid(&sid, user_info3.usr.group_ridmem[i]);
> 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.

> > ACLs:
> > Mostly done. Thanks to the acl_from_str I've been able to test it
at
> > little and there is also functions to dump an acl in human
readable
> > format (both with printf and DEBUG).
> >
> > The maximum allowed stuff is left (noone have even tried to tell
me
> > which bits it should return). Personally, I don't like it very
much as
> > I think it's mainly there to facilitate bad coding (tell me what
you
> > want or you will get EACCESS :). There 's an example to answer at
the
> > end.
>
> the say that maximum_allowed works is in SeAccessCheck.
>
> if the DesiredAccess parameter is SEC_MAXIMUM_ALLOWED then instead
of
> doing a mask-match in each individual ACE to find out whether the
> permissions desired are allowed, you RETURN the permissions of the
first
> ACE against which the user successfully matches.  this is returned
in the
> GrantedAccess out-parameter or SeAccessCheck.
>
> 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.

> > I think we
> > should keep (most of) this behaviour, but there are some bits that
are
> > specific to requests for for permissions and doesn't belong in an
ACL
> > (eg MAXIMUM_ALLOWED and the generic permissions). Do anyone have
any
>
> MAXIMUM_ALLOWED? no.
>
> generic permissions?  no.  again, genericmapping is specific to
> SeAccessCheck.  it's one of the arguments to this function, i was
> wondering what it was for!
>
> > 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.

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

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se





More information about the samba-technical mailing list