Question about vfs_acl_common not setting filesystem permissions anymore

[Ralph Böhme]

On Wed, Aug 24, 2016 at 08:32:08PM +0300, Uri Simchoni wrote:
> On 08/24/2016 04:04 PM, Ralph Böhme wrote:
> > Hi Uri,
> > 
> > *phew*! This stuff is driving me insane. As I've got to implement some
> > related improvements in the ACL code, I was working on a refactoring
> > of get_nt_acl_internal(). Got it down to 150 lines from 350. Finally
> > even I understand the logic. :)
> > 
> A common way of understanding things is to rewrite them :)

or to review. Patches coming soon, any volunteer? :)

> > On Wed, Aug 24, 2016 at 02:14:04PM +0300, Uri Simchoni wrote:
> >> Yeah you're right - it works with a create mask of 0666 for files and
> >> 0777 for dirs. That's how we use it.
> > 
> > ok, thanks for confirming.
> > 
> >> When submitting this change, I didn't get into the whole rationale -
> >> just pointed out that the new behavior is consistent with the man page,
> >> and the previous one isn't.
> > 
> > Yeah, I fully agree here. Now we just have to implement the desired
> > behaviour without bugs and unwanted side effects.
> > 
> >> If the man page said otherwise I might have suggested another option
> >> or something. What really made me do it or need it was that
> >> sometimes, and always due to lack of proper planning, we would
> >> encounter permission issues because the id mapping has changed and
> >> POSIX acls get in the way, and this in an env that couldn't care
> >> less about POSIX permissions or ACLs. The workaround was to delete
> >> all POSIX ACLs in the tree and fix file ownership and unix
> >> permissions.
> > 
> > So we have consensus that forcing create mask=0777 and directory
> > mask=0666 in the modules is the way to address this? 
>
> Yes, the other way around.

yep.

> If yes, I'll file
> > a bugreport and prepare patches. I guess we then must also force all
> > map archive|hidden|system|readonly to no.
>
> Or just force "store dos attributes" to yes

hm, while it's a reasonable setting, it might not be what all existing
setups use and I don't want to break use case B while fixing use case
A. :)

Cheerio!
-slow