Where to submit patches?

[Cole, Timothy D.]

> -----Original Message-----
> From:	David Lee [SMTP:T.D.Lee at durham.ac.uk]
> Sent:	Wednesday, August 25, 1999 6:21
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	Re: Where to submit patches?
> 
> On Wed, 25 Aug 1999, Jeremy Allison wrote:
> 
> > David Lee wrote:
> > > 
> > > 3. Allow UNIX file permissions of new files/directroies to be
> inherited
> > >    from parent directory.  (Very un-UNIX-y, I know, for us
> techno-geeks,
> > >    but an exceedingly useful and intuitive option for our user
> population
> > >    which will soon number several thousand.)
> 
> Patch attached... (including smb.conf.5.yo documentation!).
> Fuller writeup also attached ...
> 
> > Ok - this is an interesting one. I just had a long chat with
> > Andrew about this at the O'Reilly Open Source conference in
> > Monterey.
> > 
> > I'd like to throw out the following proposal to the group for
> > discussion. Neither Andrew nor I like the idea of 'dot' meta
> > files in directories to control this behaviour.
> 
> That had also been my first idea, including allowing dot files in
> subdirectories which successively override parents.  But it felt far too
> complicated (one of those gut feelings).  Also, what happens when the same
> object is accessed via different routes, such as with symbolic links?
> 
> So I, too, went off the dot-file idea.
> 
> > Currently, setting the setgid bit on a directory causes the
> > primary group to be inherited from the directory, not the
> > owner. Our idea was to add (another:-) new parameter on a
> > per-share basis :
> > 
> > "inherit permissions"
> > 
> > which would be a boolean with the following effect. If this
> > is set on a share and the directory within which the file or
> > directory is being created has the setgid bit set then the
> > permissions of the file or directory are inherited from that
> > of the directory.
> > 
> > This would allow feature to be used on a per-directory basis,
> > and would also propagate into created directories.
> 
> Sounds very like my "inherit mode"!  (Had you seen its writeup??)
> Briefly, if the share has "inherit mode" in smb.conf then:
> 1. files inherit read/write bits from the directory;
> 2. subdirectories inherit all bits;
> 3. the setgid bit has *no* samba-specific meaning; it is allowed to
>    operate as per its host UNIX system.
> Point (2) gives propagation into subdirectories.  Our proposals differ on
> point (3).  Naturally, I prefer mine...
> 
> It has double virtues: (1) it was simple to implement (2) is intuitive to,
> and easy to explain to, users.
> 
	I prefer your version of point 3 as well -- it's less likely to
result in unexpected interactions with the "native" UNIX semantics.

	There are still some cautions here:

	1. You need to be very careful that you don't introduce security
races -- i.e. if a file is created with broad permissions which are
subsequently restricted to fit with "Samba" semantics.  You need to do
something like always creating files with a umask of 0777 when the "inherit
mode" is turned on.

	2. You need to watch unexpected (and potentially subtle)
interactions with native ACLs, which may have their own ideas of inherited
modes.  a umask of 0777 may not protect against excessively broad
permissions (relative to what the Samba semantics would dictate) being
placed on the file at creation time as a result of an inherited (or default)
ACL, and the resulting security hole may be entirely invisible from the NT
side (until Samba support for native ACLs becomes more complete).
Fortunately, if I remember correctly, POSIX.6 dictates that a chmod()
operation nukes all of the optional ACL entries, so this may not be too much
of a problem.