CVS update: samba/source/smbd

Andrew Bartlett abartlet at pcug.org.au
Sat Nov 3 15:39:02 GMT 2001


"Gerald (Jerry) Carter" wrote:

> > > I don't think so. You end up with a disconnect between
> > > the group lists associated with the uid_t and the group lists
> > > in the token. This isn't a good idea (IMHO).
> >
> > I understand the concern, but I think we need to deal with this issue
> > properly.  I want Samba to run without reference to the local system,
> > for things like:
> >
> >  - Non-root mode
> >  - Non-filesystem VFS.
> 
> The "without reference to the local system" bother me a little.
> I understand why you would want this for the build farm, but I
> am not convinced it would be good for a production system

I think there is a valid case for this.  What if we run in a compleatly
non-unix VFS?

> > In particular, the combination of the two.
> >
> > Would it be sufficient to ensure that NT_USER_TOKEN is always a
> > superset of the gid_t list?
> 
> Could you convince me of
> 
>   * a good reason (example) of why this is needed

Why should I have local unix accounts (even by winbind) on my DC?

What aspect of being a domain controller actually requires local unix
users and groups?  The SAM no longer requires them.  Given that most of
the access control is done on the basis on NT_USER_TOKENs anyway what
relevance are they in any case?  Things like roaming profiles may well
be on another server, leaving netlogon and RPC.  Why can't we then map
these users to a single guest account, but still use their
NT_USER_TOKENs as before?

>   * the impact of it on the existing model of
>     failing on unknown SIDs.

I have no problem with failing on unknown SIDs, I just want to redefine
the notion of 'known'.  We already 'know' about these SIDs, they are
defined on the DC, and can be looked up.  They just don't have a local
unix mapping.   So when we don't have a local unix context (printing,
share access) why do we need to deem them unsuitable?

Note that *file* (as opposed to share) permissions are and should always
remain the kernel's responsibility (and therefore uid_t/gid_t based). 
I'm only referring to cases where file permissions can be put aside, as
they are already for many of Samba's more complex tasks.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Samba Team member, Build Farm maintainer        abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net




More information about the samba-technical mailing list