Question about vfs_acl_common not setting filesystem permissions anymore

[Uri Simchoni]

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

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

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
> 

I never know where's the right balance between flexibility and making it
easy to configure right and difficult to configure wrong, but in the
case of vfs_acl_xattr we already force some parameter if it's enabled,
so we might as well follow this path.

Thanks,
Uri.