Inconsistency in file permissions with 'blobfuse2' and 'umask' option

[landscapepainter]

Which version of blobfuse was used?

blobfuse2 version 2.2.0

Which OS distribution and version are you using?

Debian GNU/Linux 11 (bullseye)

If relevant, please share your mount command.

AZURE_STORAGE_ACCOUNT={storage_account_name} AZURE_STORAGE_SAS_TOKEN={sas_token} blobfuse2 {mount_path} --allow-other --no-symlinks -o umask=555 -o default_permissions --tmp-path {_BLOBFUSE_CACHE_DIR} --container-name {container_name}

What was the issue encountered?

Note: following is from mounted directory where the container has .gitignore and myfile in it. And I set -o umask=555 for the blobfuse2 command that mounts this container.

$ ls -la
total 0
--w--w--w- 1 azureuser azureuser 33 Jun 16 17:40 .gitignore
--w--w--w- 1 azureuser azureuser 30 Jun 16 19:35 myfile
$ cat myfile
qweqweqweqwezxc
qweqwe
qweqwe
$ ./myfile
-bash: ./myfile: Permission denied
$ whoami
azureuser

I'm currently trying to understand what would be a good set of permission to set by default, and while doing so, I have two questions:

1. I was trying to understand if the permissions set by -o umask works as expected following the permission shown from ls -la. I purposefully set -o umask=555 to check if this actually disallows every user from reading or executing the files in the mounted directory. But seems like I'm able to read the file(cat myfile) but not execute it. What is causing this behavior?

2. When I set -o umask=550, and therefore had permission of --w--w-rwx 1 azureuser azureuser 30 Jun 16 19:35 myfile, I was able to both read(cat myfile) and execute(./myfile) as well. Comparing this behavior with 1. above, seems like setting other to have permission of execute allows to execute it although owner and group cannot read/execute. Why is this the case?

3. From above, I'm thinking blobfuse2 may not behave as it seems to show.(i.e., from 1., myfile should not be read or executed considering the permission --w--w--w-, but it can be read). If this is true, what's causing this inconsistency? I'd like to understand what's going on and actually design the command to behave as exactly as I want it to.

[vibhansa-msft]

Are you mounting a HNS storage account or FNS?

• For HNS account you can set the permissions on the container and files and blobfuse will show those as the properties on the local file system
• If you are create ACLs on the account and mounted using SPN/MSI then respective ACLs and permissions will be displayed as permissions on the local file system if flag is configured to honour the ACLs (only in case of HNS account)
• when you use 'umask' you need to provide allow_other as well
• umask works as inversion so the value you give here will be inverted and shown as file system permissions (this behaviour is from libfuse driver and not a blobfuse feature)
• in the config file there is an option of setting default permissions and if you configure it for FNS account every file will show those permissions
• Who can access and who can not access is not something controlled by the blobfuse application. These permissions are sent back to kernel and it's upto linux kernel to decide who can have the access and who can not.

[vibhansa-msft]

Closing this as there are no updates, feel free to reopen if the above suggestions did not help.