starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 13:26:00 +03:00

[GH-ISSUE #680] Unexpected behavior of -o umask option #384

New issue

Open

opened 2026-03-04 01:45:01 +03:00 by kerem · 7 comments

kerem commented

2026-03-04 01:45:01 +03:00

Owner

Originally created by @berniey on GitHub (Nov 19, 2017).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/680

s3fs: V1.79(commit:unknown) with GnuTLS(gcrypt)
fuse: v2.9.4
OS: Ubuntu 16.04

mounting command:
s3fs xxx /opt/xxx -o passwd_file=/etc/passwd-file -o allow_other -o uid=33 -o umask=022 -o gid=33

/etc/fstab:
xxx /opt/xxx fuse.s3fs _netdev,allow_other,use_cache=/tmp,uid=33,umask=022,gid=33 0 0

I am using the -o umask=022 on mount point and expected the following access:
- directory: 755
- file: 644

However, I've got right 755 for both files and directories. Bugs? Or I did something wrong?

Originally created by @berniey on GitHub (Nov 19, 2017). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/680 s3fs: V1.79(commit:unknown) with GnuTLS(gcrypt) fuse: v2.9.4 OS: Ubuntu 16.04 mounting command: `s3fs xxx /opt/xxx -o passwd_file=/etc/passwd-file -o allow_other -o uid=33 -o umask=022 -o gid=33` /etc/fstab: `xxx /opt/xxx fuse.s3fs _netdev,allow_other,use_cache=/tmp,uid=33,umask=022,gid=33 0 0` I am using the -o umask=022 on mount point and expected the following access: - directory: 755 - file: 644 However, I've got right 755 for both files and directories. Bugs? Or I did something wrong?

kerem commented

2026-03-04 01:45:02 +03:00

Author

Owner

@sqlbot commented on GitHub (Nov 20, 2017):

I'm confused why you would expect umask 0022 to set files as 0644, when umask 0022 is rwxr-xr-x (0755).

@sqlbot commented on GitHub (Nov 20, 2017): I'm confused why you would expect umask 0022 to set files as 0644, when umask 0022 is `rwxr-xr-x` (0755).

kerem commented

2026-03-04 01:45:02 +03:00

Author

Owner

@berniey commented on GitHub (Nov 21, 2017):

In Unix and Linux system default for directory is 777, and 666 for file. Hence when you applies umask of 022, you get 755 for directory and 644 for a file.

@berniey commented on GitHub (Nov 21, 2017): In Unix and Linux system default for directory is 777, and 666 for file. Hence when you applies umask of 022, you get 755 for directory and 644 for a file.

kerem commented

2026-03-04 01:45:02 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 26, 2017):

@berniey @sqlbot
The result of the umask option is handled by libfuse.
Therefore, I have not thought so much about permission after umask.

FUSE sets permissions as (0777 & ~umask) for both files and directories.
https://github.com/libfuse/libfuse/blob/fuse-2_9_bugfix/lib/fuse.c#L1386-L1388

Therefore, if the umask option is 0022, the file permission is 0755.

I checked the estimate of the correction part of the code and the specification as to whether it can change to be 0644 by s3fs.

If umask=0022 sets the permissions of all regular files to 0644, files with execution authority can not exist.
Therefore, it must be 0755 for a file with execution authority.
In other words, if umask is specified, the permissions of all files are not the same, which is dependent on the permissions of the original file.
In order to realize such specifications, it is necessary to implement the umask function with s3fs instead of fuse.
If the file has execution authority, execution permission of the file will be granted unless masked by umask value.
For example, if umask=0022, the 0666 file will be 0644 and the 0777 file will be 0755.

We must consider the specification of s3fs about umask.
Should the permission of 0770 file in case of umask=0022 be 0750 or 0755?
I think it must be 0755.
In using s3fs, files that do not have x-amz-meta- * settings often cause trouble.
This workaround is to specify umask.
In the case of 0750, this workaround will be useless.

I would like to judge whether to work after thinking about the case of other mount system and FUSE client, and how the user should be.
Please comment on the implementation of umask.
Thanks in advance for your kindness.

@ggtakec commented on GitHub (Nov 26, 2017): @berniey @sqlbot The result of the umask option is handled by libfuse. Therefore, I have not thought so much about permission after umask. FUSE sets permissions as (0777 & ~umask) for both files and directories. https://github.com/libfuse/libfuse/blob/fuse-2_9_bugfix/lib/fuse.c#L1386-L1388 Therefore, if the umask option is 0022, the file permission is 0755. **I checked the estimate of the correction part of the code and the specification as to whether it can change to be 0644 by s3fs.** If umask=0022 sets the permissions of all regular files to 0644, files with execution authority can not exist. Therefore, it must be 0755 for a file with execution authority. In other words, if umask is specified, the permissions of all files are not the same, which is dependent on the permissions of the original file. In order to realize such specifications, it is necessary to implement the umask function with s3fs instead of fuse. If the file has execution authority, execution permission of the file will be granted unless masked by umask value. For example, if umask=0022, the 0666 file will be 0644 and the 0777 file will be 0755. We must consider the specification of s3fs about umask. Should the permission of 0770 file in case of umask=0022 be 0750 or 0755? I think it must be 0755. In using s3fs, files that do not have x-amz-meta- * settings often cause trouble. This workaround is to specify umask. In the case of 0750, this workaround will be useless. I would like to judge whether to work after thinking about the case of other mount system and FUSE client, and how the user should be. Please comment on the implementation of umask. Thanks in advance for your kindness.

kerem commented

2026-03-04 01:45:02 +03:00

Author

Owner

@cybertiger commented on GitHub (Dec 27, 2017):

A sensible implementation might be to have two extra options:

default_dir_mode = [default value: 0777]
default_file_mode = [default value: 0666]

Which are used when the s3 file does not have the correct metadata headers.

Excuse bad pseudocode:

if (mode_header) {
    mode = mode_header;
} else {
    if (isdir) {
        mode = default_dir_mode;
    } else {
        mode = default_file_mode;
    }
}
mode &= ~umask;

This allows people to mount files as executable if they really want (why, maybe I shouldn't ask).

@cybertiger commented on GitHub (Dec 27, 2017): A sensible implementation might be to have two extra options: default_dir_mode = [default value: 0777] default_file_mode = [default value: 0666] Which are used when the s3 file does not have the correct metadata headers. Excuse bad pseudocode: ``` if (mode_header) { mode = mode_header; } else { if (isdir) { mode = default_dir_mode; } else { mode = default_file_mode; } } mode &= ~umask; ``` This allows people to mount files as executable if they really want (why, maybe I shouldn't ask).

kerem commented

2026-03-04 01:45:02 +03:00

Author

Owner

@winglq commented on GitHub (Jan 9, 2018):

Same issue here.
I have a swift cluster and a web tool which uses swift api to create objects and folders, for example upload. Also I use s3fs to mount the same bucket to hosts. As I could not use swift api to add x-amz-meta- to objects.
If I mount the bucket with umask 0000 then all the files will have x attribute. If umask option is not used, then non-root user could not list directory.

@winglq commented on GitHub (Jan 9, 2018): Same issue here. I have a swift cluster and a web tool which uses swift api to create objects and folders, for example upload. Also I use s3fs to mount the same bucket to hosts. As I could not use swift api to add x-amz-meta- to objects. If I mount the bucket with umask 0000 then all the files will have x attribute. If umask option is not used, then non-root user could not list directory.

kerem commented

2026-03-04 01:45:02 +03:00

Author

Owner

@CMCDragonkai commented on GitHub (Sep 28, 2018):

I was caught out on this as well. @cybertiger there are apparently mount options to do such a thing: dmask and fmask, however s3fs doesn't support either options atm.

@CMCDragonkai commented on GitHub (Sep 28, 2018): I was caught out on this as well. @cybertiger there are apparently mount options to do such a thing: `dmask` and `fmask`, however `s3fs` doesn't support either options atm.

kerem commented

2026-03-04 01:45:02 +03:00

Author

Owner

@tbooth commented on GitHub (Dec 11, 2018):

Note that if your goal in setting file perms to 644 is to prevent execution, you can do this explicitly with the "-o noexec" flag. You don't gain any real security (in that you can always force the system to execute any file, and setuid considerations don't apply), and the files still appear as mode 755 (or 777 or whatever), but the flag does work as advertised and prevent direct execution.

@tbooth commented on GitHub (Dec 11, 2018): Note that if your goal in setting file perms to 644 is to prevent execution, you can do this explicitly with the "-o noexec" flag. You don't gain any real security (in that you can always force the system to execute any file, and setuid considerations don't apply), and the files still appear as mode 755 (or 777 or whatever), but the flag does work as advertised and prevent direct execution.