"Inherit Permissions" request for comments

Erick Woods erick at erick.com
Wed May 31 05:14:35 GMT 2000


NT's default behavior is UNIX+setgid, except that the gid carries (is
inherited) down into the directory structure.  Kyle's method exactly mimicks
NT, but does not allow for David's exception.  I think that David's
exception is just that, an exception.  If a goal is to mimick an NT server,
then it should, by default, behave the same.  As time goes by, we will find
that an increasing number of small business and home users are using *nix &
Samba.  Most of these folks are not going to be able to use the command
line.  We should, I think, do all we can to make sure this is a painless
process for them, whether we care to or not.  We are not here to serve
ourselves only, but the masses, as well.  Political discussions aside, I
also consider the current default 'inheritance' behavior to be a security
risk, having an alternate owner from that of the owner of a home directory
is a very bad idea  i.e. having a publicly accessible folder in /home/bill.
No one should have access to ANYTHING under another users home directory.
Period.  That is a poor implementation of security in any model.

My 2¢


Erick Woods


----- Original Message -----
From: David Lee <T.D.Lee at durham.ac.uk>
To: Multiple recipients of list SAMBA-TECHNICAL <samba-technical at samba.org>
Sent: Tuesday, May 30, 2000 8:21 PM
Subject: Re: "Inherit Permissions" request for comments


On Mon, 29 May 2000, David Collier-Brown wrote:

> Kyle Herbert wrote:
> > 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.
>
> This seems sane, and hopefully will reduce the effective
> complexity of the various create mask options...

.. except that "inherit permissions" already overrides all the "create
mask" options, even those called "force ...".  Thus all that complexity is
not only reduced, it is removed when "inherit ..." is the determinant.

In another message, just posted, I suggest a new:
  inherit group owner = { yes | no }

which allows the functionality to work either way.  Indeed, in the absence
of "inherit permissions" it also allows UNIX/setgid to be simulated, which
can be regarded as a different flavour of "force group".


> > 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,
>
> We've simulated Unix features before (indeed, with the
> create masks), so this is a credible direction.
>
> In addition, I'll propose that merely mapping an existing
> Unix feature to Samba is inherently a better idea than
> inventing a new one.

.. hence the suggested "inherit group owner" above.

I know nothing about NT permissions.  But I gather (am I correct?) that
NT's natural behaviour is similar to UNIX+setgid.  We'd need to consider
the similarities and any differences in any implementation in Samba.

Hope that helps.

--

:  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