Question about vfs_acl_common not setting filesystem permissions anymore

[Ralph Böhme]

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. :)

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? 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.

Cheerio!
-slow