Michael Stockman pgmtekn-micke at
Thu Feb 24 10:27:34 GMT 2000


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

On the samba server, yes you do.

We've defined that samba is within the UNIX architecture.

A user on a samba system is a unix user, mapped to an actually virtual
NT user (same with groups). It should be possible to map between the
two (saying that unix user john corresponds to NT's user JohnDoe in
domain xyz). The issue is the same as the SURS discussion has rehashed
sooo many times, a virtual NT user may not be in the local samba
server's domain (which would make him a mapped external NT user) but
does most certainly correspond to a local unix user.

On the computer a unix user have got a set of group memberships,
regardless of whether if he also has an account on another system and
that account have group memberships. We cannot override this and grab
local group memberships from a remote system, which may not even know
about unix and samba. However, if someone would ask us about the group
memberships of a mapped external NT user (could this happen?), we
should tell them what the remote domain told us.

> if the PDC is in fact a samba server, and it created the groups from
> local unix system, and the two local unix systems use the same
> 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.
> 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
> system.  group_rids converted to gid_t with *its* local SURS table
> gid_t* groups relevant ONLY to that local unix system (hi jeremy,
> taught me this one :)

This should not happen. If the RID is obtained from the network it
must be looked up on the local system (not may be looked up). gid_s
from a remote system are completely meaningless to us.

> for those people who may be thinking, "eh???", here's the crunch: a)
> two local SURS tables *may* contain identical lookups b) this
results in
> both local unix systems following the posix convention of usnign the
> local uids and gids to give the impression that both systems have
> 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.

So, in cases where samba is a PDC we'll only need to do the lookup
once (when we create the NET_USER_INFO3 struct, on login) and when we
are domain members (etc.) we'll need to do a lookup once (when we get
sent a NET_USER_INFO3 struct, on login). Ok, this was easy :-).

> > Well, even NT has banned them from ACLs. Don't let the fact that
> > 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
> .. oh god.  well, that only makes the implementation of
> complicated, nothing else.

Not much, most bits are shared, except that some are only allowed in
one and not in the other. I'm thinking of possibly hijacking some
unused bits in the ACL.

> ACLs and security descriptors are... pretty dumb.  you can put
> 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
> > why):
> > > > ACE allows 0x7FFF
> > > > ACE denies 0x0001
> > > > ACE allows 0x8000
> > > > These three ACEs apply to the user.
> hey, that's so cool!  it _is_ an effective acl, it's just not
> what's going in, and trying to create a MAXIMUM_ALLOWED is
impossible :-)
> :-)

--- from (my creation) ---
access_mask acl_get_max_allowed( ACL *pacl, access_info *pai )
  pacl = pointer to ACL structure
  pai = pointer to access_info structure

Traverses an ACL collecting allow and deny bits for the user. It stops
when it
finds an ACE with deny bits after the first allowing ACE (but that ACE
is not
evaluated), or at the end of the ACL. The return is then all allow
collected up until the breakpoint with denied bits masked out.
See acl_check_access for info about the access_info structure.

Example ACL, all ACEs are assumed to be applicable to the user
ACE denies 0x000F
ACE denies 0x0010
ACE allows 0x007F
ACE allows 0x0080 <- The acl is evaluated to here
ACE denies 0x0100
ACE allows 0xFE00
The return value will be 0x00E0, all allowed bits (0x00FF) with the
bits (0x001F) masked out. The denied 0x0100 is never evaluated in this
and would not affect an access check for the returned bits.

Return value:
  access_mask with the user's allowed access to an object
--- end of cut ---

The return value will be 0x7FFF. This is a simple scheme, but I think
it will do. It avoids many complicated questions like, is it better to
have bit 5 instead of bit 4? Are bits 7 and 8 better than bit 2? One
could also imagine not breaking until an ACE that denies a bit
currently allowed, but it'll get harder to determine in advance what
result can be expected for a given nontrivial ACL. Or why not wait
until you find an ACE that denies more bits than it allows (ok, I'll
do without bit 4 if I can have 8 and 10 instead)? No, I think simple
is good.

Best regards
  Michael Stockman
  pgmtekn-micke at

PS Sorry about the lengthy NT/UNIX user stuff in the beginning, I
couldn't resist.

More information about the samba-technical mailing list