fuse does not handle umask correctly

[Eyal Lotem]

umask is supposed to mask away some permission bits.

In fuse, the umask parameter instead overrides all permission bits.

Overriding the permissions from the file system itself might be a useful feature - but it should not be named umask.

I have attached a patch that fixes the behavior of umask. It may be desireable to also add a uoverride or such parameter to emulate the current umask behavior when applying the patch.

I have also checked the security vulnerability checkbox, because in my case, for example, the umask allows write access when it shouldn't, and avoiding umask allows many permissions that should not be allowed.

[Kees Cook (kees)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. I don't see this behavior. What settings are you using, and on what fuse filesystem type?

[Sam Hocevar (sam-h)]

I see the behaviour using sshfs and umask=002, with no other option passed to sshfs.

1) All remote files appear locally with incorrect permissions, most annoyingly with the +x flag.

2) Touching files creates them remotely as 644 instead of 664.

[Sam Hocevar (sam-h)]

The attached patch fixes the wrong displayed permission problem, but does not fix the wrong creation flags. Setting the local umask to 002 too, besides being something I'd like to avoid, does not change the behaviour.

[Michael Terry (mterry)]

I unchecked the 'security vulnerability' flag because in my testing, it doesn't actually allow more permissions to the user, it just looks like it will.

That is, this is a display issue only. fuse's umask seems to only affect the display of the bits, it doesn't actually change them.

Thus, this bug is two-fold. We can apply the patch to fix the display issue (that is, use of umask will *look* like it works, rather than now, where it looks like all hell broke loose). But the underlying problem that umask doesn't seem to actually do anything (in terms of changing permissions to read/write) also should be addressed, otherwise what's the point?

[Michael Terry (mterry)]

I asked the fuse mailing list about this. Here is their answer (interspersed with my initial email):

"""
> '-o umask=' seems to:
> (A) have an odd display bug because of a missing ampersand (see [1]) and

It's a feature not a bug. Notice, how other filesystems like msdos
also use -oumask mount option in this sense.

> (B) not actually affect the permissions of the fuse user. That is, a
> umask of 444 will (with or without the display bug fixed) still allow
> the fuse user the same exact read permissions as the underlying file
> would.

That is also a feature. Unless the '-odefault_permissions' option is
given the filesystem is responsible for permission checking (which
sshfs duly does: you can only access the filesystem according to your
permissions on the server side).
"""

Are they right, that the umask usage is appropriate? If so, I guess there's no bug?

[Marc Deslauriers (mdeslaur)]

Since upstream doesn't consider this to be a bug, I'm closing this issue.

[Narcis Garcia (narcisgarcia)]

A new guide to understand better the umask management:
http://wiki.lapipaplena.org/index.php/How_to_mount_SFTP_accesses

(with special care with owners and permissions questions)