"Inherit Permissions" request for comments

[David Lee]

On Wed, 31 May 2000, David Lee wrote:

> [...]
> The principles need further exploration.  We need a table of how any
> proposed "inherit group owner" functionality (however implemented) would
> interact with UNIX+setgid.  Needed: a volunteer (and here I take a step
> back) to step forward, please. 

So everyone else took two steps back, did they?  Sneaky.

> Possible issues to consider:
> 
> 1.  Are there some flavours of UNIX that lack setgid functionality on
>     directories (reminder: setgid on directory on most UNIXes means
>     inherit group owner)?
> 
> 2.  Are there some other operating systems on which Samba runs that lack
>     setgid on directories?
> 
> 3.  Kyle's suggestion that "inherit group owner" functionality should be
>     default (or at least, easily and reliably settable) is important
>     for environments where the UNIX view of the filestore is irrelevant.
>     (At our site, the UNIX view is highly relevant.)
> 
> 4.  Current behaviour ("inherit group owner" functionality) gives full
>     flexibility, but requires some UNIX knowledge by user and/or the
>     system-administrator/helpdesk.

Having the ability to inherit group-owner, irrespective of setgid seems to
have wide support.  Indeed, one lobby reckons that this should be the
default.  They make a good case.  Ideally I'd like to keep separate
discussion of possible behaviours from settings of defaults until the last
minute.   But in practice, I think it will have to impinge somewhat
earlier.

Let us assume a new parameter "inherit group owner = {yes|no}" which, for
brevity, I call "igo".  (I also use "setgid" to mean the setting of the
setgid bit on the parent directory.)

How does "igo" interact with "setgid", when they conflict?

                igo: no   igo: yes
               +--------+---------+
   setgid: no  |    p   |    d    |
               +--------+---------+
   setgid: yes |    ?   |    d    |
               +--------+---------+

where "p" means use group of process, "d" means use group of directory.

(Note that the "setgid: no" row also covers those systems which don't have
a setgid concept on directories.)

Three cases are obvious, and should cause no dispute.

The tricky one is { igo==no && setgid==yes }.  Which takes precedence? 
Does the share-administrator intend to override setgid, so setting "p"
from the process?  This goes against both UNIX, and the consensus of this
discussion.  Or to allow setgid to follow its natural course? 

My own view is coming round to encouraging using the directory's group and
discouraging using the process's group.  That is, that the "?" become "d"
in the table above.  We end up with:

   if (igo == yes) {
      make all reasonable efforts to adopt group-owner of directory,
      irrespective of setgid bit
   }
   else {
      follow setgid bit
   }

One remaining question: the default.  The current behaviour is equivalent
to "igo == no".  Are there any compelling issues one way (UNIX semantics,
igo==no) or the other (NT semantics, igo==yes)?  If not, we just need a
consensus from interested parties.  Someone needs to do an opinion poll.

Seem OK?

-- 

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