inherit mode

David Lee T.D.Lee at durham.ac.uk
Thu Sep 2 10:01:52 GMT 1999


On Thu, 2 Sep 1999, Jeremy Allison wrote:

> > David Lee wrote:
> > 
> > > So instead of "inherit mode" being a simple boolean, perhaps it could
> > > be a multi-valued switch: no/yes/setgid:
> > > o  "no" (default) would maintain existing behaviour;
> > > o  "yes" would give my simple-to-explain per-share action;
> > > o  "setgid" would give Allison/Bakun "only applies to setgid".
> 
> I really like this also. I don't like the parameter name (how about
> "inherit security" instead ?) but other than that this seems to be
> the best option.

I picked the name "inherit mode" because that was what "create ...",
"force ...", "directory ..." seemed to use.

The people who see this phrase "inherit mode" (or whatever is chosen) are
samba administrators, who are configuring their UNIX system.  A major
advantage of the word "mode" (or "permissions")  is that it is UNIX-y, and
that what we are talking about is inheritance of UNIX-y thingies.  The
word might "security" distract, potentially harmfully, from this.

In one sense, the phrase doesn't matter.  But in another sense,
particularly to relatively inexperienced admins (whose inexperience may be
in either or both UNIX or/and SMB), an ill-chosen word can mislead. 

Indeed see below, where even very experienced folks find a word's implied
meaning to be distracting ... 

> > Although, how force mode interacts with inherit mode is another story. 
> > I think technically Jeremy is correct in saying that force mode
> > overrides inherit mode (after all, that's what "force" means), but in
> > practice, I think that using force mode and "inherit mode = yes" should
> > be undefined (or, one or the other should be ignored and generate a
> > warning in the log), and that "inherit mode = setgid" overrides the
> > value given to force mode.  This makes force mode work on files not
> > within setgid directories -- which I think is the most flexible
> > behavior. 
> 
> Ok - I'm beoming convinced that setting "inherit security" should
> override force mode if not set to "no". This is starting to make
> more sense.

The word "force" made sense when it was simply the opposite of "mask". 
But this "inherit mode" concept introduces ambiguity into the old word
"force", which we need to resolve. 

I think we are all agreed that the "inherit mode" concept takes precedence
over Samba's traditional mask/force concepts.  In other words, "force" 
(and "mask") are only invoked in the absence of "inherit mode".  (So
"force" is not "forced" when "inherit mode" acts!  See what I mean about
potentially misleading and confusing interpretations of words??) 

I think we have agreed on the behaviour of "inherit mode" (or whatever we
call it):

(1) no (default): fall through to existing mask/force behaviour;
(2) yes:          inherit bits from parent-dir:
                     files just rw-rw-rw- bits
                     directories all bits (including setgid, sticky, ...);
(3) setgid:       if parent-dir has setgid then (2) else (1).


> > Overall, I think inherit mode is close to The Right Thing(tm).  I know
> > there has been some debate in the past about having Samba implement
> > it's own permissions structure, and I think inherit mode allows samba
> > to operate much more smoothly with UNIX semantics than was possible
> > before. 
> 
> Yes, it is definately a win.

Glad the idea is useful and approved!

> I'm out doing talks until Sept 12th or so, and will start
> on coding this up for the next release (or maybe target
> 2.2.x) once I return.

Remember that I have a 2.0.4b patch for the original simple "yes"/"no" 
behaviour, including the yodl smb.conf.5 documentation.  This should make
a useful starting point. If you wish, I could adapt this to include
"setgid"  behaviour and/or do it against 2.0.5a or whatever the latest
stable release is.

Technical note: the "unix_mode()" function, called from several places,
requires an additional argument (file/directory name).  Recent 2.0.{2,3,4}
changes have been in areas where this function is called, which impacts on
tracking the patch against the releases.

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/~dcl0tdl            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :



More information about the samba-technical mailing list