"Inherit Permissions" request for comments

David Lee T.D.Lee at durham.ac.uk
Tue May 30 11:41:23 GMT 2000

On Sun, 28 May 2000, Kyle Herbert wrote:

> Thanks for the encouragement, David!  As you suggested, I'd like to start a
> thread and get some input regarding the "inherit permissions" feature you
> introduced in version 2.0.7.  As much needed an addition as it is, I still
> believe there is a fundamental security issue.

Kyle originally put this topic onto the "samba" list;  I replied there,
but also suggested that "samba-technical" was a more appropriate forum.

My reply to that (putting the case for "the defence"!) is included here,
about 25 lines below. 

Briefly:  I see Kyle's point of view.  But I am not convinced that his
solution is the best way forward either philosophically (because it is a
replacement, not an alternative) or as an implementation.  But at the end
of this message I then suggest how to keep both of us happy.

> My premise is simple:  to inherit group permissions for a new file or
> sub-directory from the parent directory without also inheriting the group
> ownership of the new file or sub-directory from the parent directory is an
> exploitable flaw in security.  (i.e.  Inheriting the write attribute for the
> group-owner looses its meaning when the group-owner is altered.)
> The current implementation of the "inherit permissions" feature in Samba
> 2.0.7 is 'flawed' (or 'featured' depending upon your point of view ;-) in
> this way.  I devised the attached patch to correct this in hopes that in
> some form it would be included in the next Samba release.
> [...]
> I'd like to hear other people's opinions.  Rather than patching Samba,
> closing this security hole can be achieved by requiring the sysadmin to use
> setgid on the share directory at the operating system level.  This
> requirement, however, can only be enforced via documentation, which is poor
> enforcement at best and requires an extra step in administration.  Perhaps
> there is a better solution?  How can the behavior of an NT file server be
> most closely approximated?

My earlier reply, defending the current behaviour of "inherit permissions" 
is boxed below: 

| Bear in mind throughout that a principal aim of this mode is for home
| directories at large installations (many thousands of users) using a
| single [homes] share, where most users need have no real knowledge of
| UNIX.  Thus the UNIX/Samba administrator needs to be able to set up
| [homes] to get things 98% intuitive for 98% of them 98% of the time.
| There will always be the remaining 2% who need greater flexibility:
| let them learn UNIX!
| The issue can be argued either way.  So let me put "the other side".
| In setting the read/write bits, "inherit permissions" adds new, useful
| functionality which is not already there.  By contrast the principles of
| "setgid" on directories are already implemented within most UNIX systems.
| So if "inherit permissions" were to force "setgid" behaviour, regardless
| of the "setgid" bit itself, this actually removes flexibility (it will
| have disabled an infrequently used, but useful, switch).
| One could well envisage the following home directory structure (thousands
| of users, remember, in [homes]):
|   .              :  711  (private as possible, just enough through-access)
|   ./public_html  :  755  (public)
|   ./normalgroup  :  750  (group-access to my usual group)
|   ./specialgroup : 2750  (owned by non-default group; setgid bit set).
| All new files and subdirectories (recursively), except those in the three
| special cases, get 600 (files) or 711 (directories) and the normal group.
| All new files/subdirectories in "public_html" get 644/755 and the normal
| group.
| All new files/subdirectories in "normalgroup" get 640/750 and the normal
| group.
| All new files/subdirectories in "specialgroup" get 640/2750 : the
| group-owner is set via the setgid bit, using the owner of the directory.
| This gives reasonably full functionality.  By contrast, if "inherit
| permissions" were to force setgid, then we would have lost an aspect of
| flexibility.
| So my own view, on balance, is to keep the existing functionality.

However, I sympathise with Kyle's viewpoint.  Indeed, I seem to recall
that when we originally discussed this topic way back on this list, we
considered this aspect and even came up with a hypothetical (and
definitely not final!) syntax: 
   inherit permissions = { yes | no | setgid }
(a weird mixture of boolean and string!) to allow both types of behaviours
"yes" as at present, "setgid" to inherit also the group owner.

That syntax is indefensible, so ignore it.  But Kyle's message points out
the desirablity of (optionally) inheriting group-owner, irrespective of
UNIX/setgid setting.

Perhaps we need a new parameter as an adjunct: 
   inherit group owner = { yes | no }

Two aspects:
1. with "inherit permissions" its meaning is (I hope!) obvious.  It
   applies, irrespective of any UNIX "setgid" bits encountered.

2. without "inherit permissions", its behaviour is as above.  It can be
   regarded as a different flavour of "force group".

> I think I've got the best solution nailed, but ...   Anyone care to comment?
> [...]
> --- uid.c.original      Thu May 11 04:57:19 2000
> +++ uid.c       Sat May 13 12:17:30 2000
> @@ -160,9 +160,11 @@
> [...]

An observation (and it is only that, not a criticism) is that the original
"inherit permissions" facility is implemented self-contained within
"smbd/dosmode.c".  This particular patch from Kyle steps outside those
bounds.  ("dosmode.c" is about handling the file; "uid.c" is about
handling the uid/gid of the process.)

So which is the most appropriate place to implement the functionality?

Summary of my suggestions:

1. Keep "inherit permissions" as it is;
2. Add "inherit group owner = { yes | no }";
3. Consider whether to implement in "dosmode.c" or "uid.c".


:  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