When creating a new file/directory, we need to obey the create mask/directory mask parameters.

Jeremy Allison jra at samba.org
Tue Oct 2 21:35:31 MDT 2012

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.

The correct fix is to remove the security mask,force security mode,
directory mask, force directory mode parameter. If you want to
delay 4.0.0 whilst I conduct a poll of users to ensure they are
not currently using these parameters and will not object to their
removal on samba-technical I'm not averse to making the
proper fix for 4.0.0.

What you're suggesting, passing a bool into the VFS saying
"this operation is really atomic" is a *worse* fix than the
one that is currently in master. That truely is a bad idea.
I will veto such a fix.


More information about the samba-technical mailing list