When creating a new file/directory, we need to obey the create mask/directory mask parameters.
abartlet at samba.org
Tue Oct 2 21:47:28 MDT 2012
On Tue, 2012-10-02 at 20:35 -0700, Jeremy Allison wrote:
> On Wed, Oct 03, 2012 at 12:56:13PM +1000, Andrew Bartlett wrote:
> > On Tue, 2012-10-02 at 16:41 -0700, Jeremy Allison wrote:
> > > On Wed, Oct 03, 2012 at 09:16:42AM +1000, Andrew Bartlett wrote:
> > > >
> > > > Can you please rework this to pass in a file/directory flag?
> > >
> > > Oh yeah, I missed this on first reading. It's actually
> > > nothing to do whether it's a file or directory, so such
> > > a flag would be irrelevant (in fact the fsp pointer
> > > already knows this).
> > >
> > > It's actually about whether this is a security
> > > descriptor inheritance set on create, or a
> > > security descriptor modification, for which
> > > we have two separate parameters:
> > >
> > > create mask/security mask for files.
> > > directory mask/directory security mask for directories.
> > >
> > > For 4.1, we might want to think instead about
> > > merging these two parameters (which are a
> > > historical accident based on user needs)
> > > and simply have one mask which is applied
> > > uniformly on ACL inheritance create and ACL
> > > change, in which case the whole problem just
> > > goes away.
> > I would much prefer we did that merge for 4.0 than having this patch
> > make it into 4.0 as-is. Or, if we don't want to do this, pass in
> > whatever metadata information you need to use the correct parameter.
> > I'm opposed to this patch making it onto 4.0 as-is.
> Well luckily you're not the maintainer for the ACL
> code in the fileserver, so you don't get to make
> that decision.
Jeremy, I really don't think you want to start playing maintainer trumps
here. The change I object to is the change to the loadparm layer to
introduce (essentially) a new read/write global variable.
We should be avoiding global variables in general, and particularly the
abuse of global variables in this subtle and confusing way.
That we are so close to a release is no excuse to put aside good
software engineering practice. Indeed, it is every reason to apply that
rigour even more strongly.
I remain opposed the the patches as is.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical