[Samba] Issues with FLOCK on NFS Share

[Christopher Cox]

On 7/6/20 11:00 AM, Rowland penny via samba wrote:
> On 06/07/2020 16:29, Georg.Biberger--- via samba wrote:
>> Hello,
>>
>> Get same output with "getent passwd qqeda11" and with "cat /etc/passwd | grep 
>> 'qqeda11'"
>> qqeda11:x:79846:65600:Project Account for EDA:/home/qqeda11:/bin/bash
>> When you say it is not supported, do you mean it is not supported by samba, or 
>> by what else?
>>
>> Georg
>>
> It isn't supported by Samba.
> 
> the 'passwd' line in /etc/nsswitch.conf is probably something like this:
> 
> passwd:  compat winbind
> 
> Though 'compat' might be 'files'
> 
> What this means is search in /etc/passwd for your user, return if found, if not 
> found, search via winbind (in AD)
> 
> So if you run 'getent passwd qqeda11' with 'qqeda11' in /etc/passwd, then this 
> the user that will be returned and the user in AD will be ignored.
> 
> The LOCAL Unix user != the Domain user
> 

IMHO, these discussion are beneficial.  "compat" traces back to NIS (mostly), so 
usually means a "combo" search of "+/-" style NIS or other allow/deny sources in 
addition to /etc/passwd (group, etc.).

This may muddy the waters a bit, but this what I wrote in our ansible module
that creates users.

#
# IMPORTANT: There are namespaces in Linux (as in most Unix).  Therefore,
# it is possible for there to be a local Linux account defined in
# /etc/passwd, /etc/shadow, etc. and a like named account coming in from
# a different namespace source of identity, e.g. samba/winbind.
#
# nsswitch.conf which is read once by processes that need to know about
# namespaces, can therefore attempt, for example, authentication, against
# multiple disparate identity sources when auth is requested for a name
# that exists in multiple namespaces.  While nsswitch.conf determines order
# of lookup, other "things" (like PAM) might thwart further lookup and
# actions.
#
# This ambiguity can be a feature or curse.  Just note that things like
# adding a user to be a local Linux account (/etc/passwd, etc) may fail
# if the user can be found already inside a different namespace.  Why does
# this matter?  Consider provisioning a host with a set of local users.
# And then later joining the same box to a Windows domain using winbind.
# If there are usernames matching both in the list of provisioned local
# users and now via winbind (samba joined to a AD domain), you  create the
# scenario of ambiguity.  Depending on how a session is established for
# a user found in both namespaces determines their real identity (uid).
# Note, this same ambiguity can be created for system level users that are
# defined in AD as well. In other words, even without any provisioning of
# local users, this problem is possible.  If there's any good news, is
# usually login is disabled for such local users Linux side (so session
# confusion is less), but the namespace ambiguity (collision) still exists.
#
# Let's say that you, as mentioned above, provision local Linux accounts
# using some sort of CM or other mechanism.  After a target host is running
# winbind after joining a domain, calls to create and/or manipulate users
# may fail or give unexpected results since there is now ambiguity.
#
# But let's say you still want those local accounts, that is, you will
# actually be creating a local user for which there is already one in
# winbind. The way you'd have to do this is to disable the other namespaces
# (winbind).  One way to do this would be to shutdown winbind in order to
# create or manipulate local users. Once done, winbind can be re-enabled.
# Just realize that you now have the same username defined in different
# namespaces, and thus depending on how a session is established, a
# different real uid identity for the same username.
#
# Other problems.  The namespace origins do not understand each other
# (most of the time).  While some tools might query, for example, using getent,
# to determine user existence, and getent passwd, for example, searches
# multiple namespaces, other tools might not and might make assumptions and
# operate solely with regards to their own namespace.  Some tools may do a
# little of both.  Might query multiple namespaces, but make manipulation
# assumptions based on one namespace.
#
# Linux can see and somewhat understand multiple namespaces.  However, other
# systems that you might be dependent upon for identity, likely don't know
# anything about local users on your Linux host (duh).  The ability for Linux
# to "smash" multiple identities by name could be a feature.  However, because
# of this multiple identify ambiguity, it can also cause confusion.
#
# nsswitch.conf, ideally, but again, read once by service processes, can
# determine order of name lookup.  However, rules inside of a PAM (Pluggable
# Authentication Modules) stack can actually implement a different forced
# ordering based on how an individual module works or ordering there.  Again,
# this can be a feature or curse.  In short, anytime you have multiple disparate
# namespaces, you have the opportunity for this sort of ambiguity.  But
# obviously, querying against multiple sources of auth is a feature, the curse
# usually comes in the form of session identity (or rule stacks like PAM).
#
# I could write a book on this. And we just mostly picked on local
# users vs. samba and didn't touch on NIS, LDAP, rfc2307 and interesting things
# from the past like Windows Service For Unix (SFU) (what I'm trying to say is
# that identify ambiguity caused by different namespaces, and the features and
# curses it creates, have been around a very very long time).
#
# One possible mitigation, is where possible (and this is not 100%), you
# can attempt to ensure the same uids (and gids, service ids, etc) in all
# sources. Just remember, these namespace owners don't usually respect one
# another.  So success cannot be guaranteed, even if working at first.  Just as
# a simple case, when there are multiple disparate sources, even if agreement
# can be made initially with regards to uid session identity, as modifications
# get made independently over time, there is great likelihood that that
# preserving unified agreements will degrade to the point of disagreement. Why?
# Because the sources are disparate.  If you can somehow force control of every
# namespace through a common control that understands and can manipulate all the
# namespaces, then, in theory, you might be able to maintain consistency across
# the namespaces.  But you might have to control entire systems (e.g. operating
# systems) in total.  And such deep embedding of control is probably not
# possible, not entirely.
#