ACL / SDs

[Luke Kenneth Casson Leighton]

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

yes.  limited as it is, powerful in its simplicity.
 
> 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).

yep.

> The issue is the same as the SURS discussion has rehashed
> sooo many times,

i know.

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

i know what you mean, here, about "mapped external NT suser".  i consider,
however, ALL nt users to be virtual and to AVE to have a correspondance
with a local unix user (one-to-one, respective to the local Unix sstem).

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

[speaking hypothetically, here, not factually] ah - yes we can.  each NT
membership shall be mapped to a gid_t on the *local* unix system.


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

no, again, by your argument above, namely that even what you define to be
a mapped external NT user [clarification: a trusted domain user], the
virtual NT user still has to be mapped, on--to-one, with a local unix
user.  it's no different from a mapped non-external NT user
[clarification: a user of the samba-controlled domain], right?

therefore, why should that user be expected to be treated differently with
respect to its groups?


i have been wondering about this issue for quite some time.  how, when you
create some groups on the NT-side, do you actually _do_ anything with
them? :)

i mean, they're pretty pointless, and they clash with the unix groups,
giving people a false impression.

you give a user some membership of some unixgroups, and they are actually
granted something completely different, nt-wise.

eh????

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

absolutely corrrect.  i didn't say gid_s from a remte system, did i,
though?

i said group_rids.

that's totally different.

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

yep.

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

yep.

i think this should be a smb.conf option thing.  "obey unix local groups"
or "translate NET_USER_INFO3 group_rids to unix local groups".

we can sell this as "being faster" because you don't have to do a
getgroups() twice for the same user (once on the PDC, once on the domain
member) for the same login.

and hope like hell that the SURS implementation is fast :)

> 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
> bits
> collected up until the breakpoint with denied bits masked out.

ok.