fuse: pass default_options

[blueyed]

llfuse's documentation recommends using llfuse.default_options.

I've tried this, and it appears to work.

In particular "default_permissions" might be useful for performance reasons.

I'd be happy to provide a PR for this, if you agree that it makes sense.

[ThomasWaldmann]

>>> import llfuse
>>> llfuse.default_options
frozenset({'default_permissions', 'no_splice_read', 'nonempty', 'splice_move', 'splice_write', 'big_writes'}) 

Not sure what they all mean, whether they make sense for us or since when default_options is available in llfuse.

So, double check that please and then do a PR. :)

[blueyed]

default_options is there since release-0.42~61(1d8c8e0): python-llfuse/python-llfuse@1d8c8e0. Do you want to bump the required version, or should be duplicate it for older versions?

See python-llfuse/python-llfuse#12 about the documentation for its values.

default_permissions seems to be crucial: without it, I can access a mount with -o uid=1001,umask=077 as user 1000!

[ThomasWaldmann]

Hmm, somehow embarassing that the default_options must be explicitly given and are not the default(*)...

Same for the default_permissions.

(*) in fact, they are the default value for the init argument. but that's not practically helpful as in many cases one needs to pass other options there, so the argument default is not used.

[ThomasWaldmann]

@blueyed can you evaluate whether this means a security or performance issue for:

• borg 1.1.x (x < 6) or borg 1.0.y - no uid, gid, umask options implemented there
• borg >= 1.1.6 (with new uid, gid, umask options)

[ThomasWaldmann]

related PRs: #3769 (#3843 is the fwd port to master, no backport to 1.0 yet)

[ThomasWaldmann]

@blueyed do not bump the required version, but use something like:

default_options = frozenset(...)  # copied from llfuse, to support pre-0.42 llfuse
default_options = getattr(llfuse, 'default_options', default_options)
...

[ThomasWaldmann]

@blueyed you said In particular "default_permissions" might be useful for performance reasons..

Did you mean security reasons? If not, can you explain the performance impact?

[blueyed]

By now I would say "security reasons", but initially I've read something along that otherwise the program would have to do checks, which might be slower then.
borg's fuse driver does not do any checks however, so it would be slower probably, but for good reasons. The other options should improve performance though I guess.

[ThomasWaldmann]

considering the PRs have been merged into master and 1.1-maint, guess we can close this?

[ThomasWaldmann]

ehrm, looks like I misinterpreted my own comment #3903 (comment) - "related" did not mean this issue has been fixed there, just related stuff...

reopening...

[ThomasWaldmann]

ok, looks like we need a security fix here, I am working on this currently and will release 1.1.9 ASAP.

@LocutusOfBorg can you help with getting a CVE for this?

A) When borg mount -o allow_other ... is used (for this to work, it needs to be allowed via /etc/fuse.conf and user_allow_other in there) the FUSE subsystem principally allows access by other UIDs than the uid which did the borg mount.

B) If allow_other is not used, FUSE does not allow any access by other users, so no problem here. If allow_root is used, there is also no problem as root is able to access everything anyway.

C) As unfixed borg versions did not give default_permissions to llfuse.init(), it did not request that UID/GID/mode-based permissions are checked / enforced by the kernel.

A) and C) together mean that uid/gid/mode as present in a borg archive are visible (e.g. ls -l), but are not enforced, which is unsecure and unexpected(*).

(*) This is especially the case if the UIDs/GIDs stored in the borg archive match the system executing the mount - then users would likely expect it behaving like a local filesystem, enforcing permissions perfectly. If UIDs/GIDs do not match between system and archive, there is a fundamental problem with that mismatch, of course (this is not borgfs specific, but happens with all filesystems).

[ThomasWaldmann]

@blueyed could you review the PRs?

[ThomasWaldmann]

Bah, this is a mess. :-(

From mount.fuse(8):

       default_permissions
              By  default  FUSE  doesn't check file access permissions,
              the filesystem is free to implement it's access policy or
              leave it to the underlying file access mechanism (e.g. in
              case of network filesystems).
              This option enables permission checking, restricting access based on file mode.
              This is option is usually useful together with the allow_other mount option.

So, the llfuse docs recommend llfuse users (== [borg] developers) use default_options (which sets default_permissions) and give that to llfuse.init().

OTOH, the mount.fuse(8) man page says checking permissions is NOT the default and users need to give that mount option if they want checking.

OTOH, the name default_permissions somehow seems to indicate that this should be on by default.

A related problem is: if we give some options by default, how does one get rid of them in case one wants different behaviour? It looks like llfuse implements some stuff like no_read_splice, but there is no no_default_permissions...

[ThomasWaldmann]

nitpick: the filesystem is free to implement **it's** access policy - note the wrong apostrophe.

[ThomasWaldmann]

related: libfuse/libfuse#15

[ThomasWaldmann]

any comments about how to deal with this?

[Nikratio]

default_options has to be passed explicitly so that you can filter out options that you do not want.

[ThomasWaldmann]

@Nikratio passed where by whom? do you mean by the end user to mount.fuse on the shell?

[ThomasWaldmann]

I updated PR #4331 according to these ideas:

• have secure internal default in borg mount (== enforce default_permissions)
• if a user does not want that, revoking is possible with a custom ignore_permissions mount option
• keep out of the way of / do no magic with all other fuse options, the user who mounts gets what they specify
• document OUR options, point to mount.fuse docs for everything else.
• leave cleaning up this mess to llfuse / fuse / kernel people.

[ThomasWaldmann]

@LocutusOfBorg considering that mount.fuse documents that there is no permissions checking, I guess borg does not need a CVE, sorry for the noise.

Not sure if that is a sane situation in fuse/kernel, but that's not our problem.

After the PR we will at least keep users from falling into that pitfall accidentally.

[Nikratio]

Passed to llfuse.init() by the program that uses python-llfuse. As http://www.rath.org/llfuse-docs/data.html says, "This is a recommended set of options that should be passed to llfuse.init to get reasonable behavior and performance. ".

[ThomasWaldmann]

@Nikratio ah. well, as you've maybe read above, that has its issues.

what i did not talk about yet are potential platform issues (like some platform not supporting some option or some platform requiring some option). i didn't feel like inventing a negated (or negated negated) option just for the case somebody running into such an issue for all the options in llfuse.default_options. i did that for default_permissions.

what (ll)fuse could do better here is at least have all options in negated and non-negated form.

[Nikratio]

The default options are platform-dependent. If a platform doesn't support an option, then on that platform it will never be included in default_options. For negation, I don't understand why
llfuse.main(default_options + { 'no_foo'}) is better than llfuse.main(default_options - {'foo'}). Actually, the former raises the question why no_foo should take precedence over foo.

[ThomasWaldmann]

platform dependency: ok, sounds good. i thought i have seen some code removing some options for macOS, but I don't remember it exactly.

assuming that 1) a software calls llfuse.init() and uses llfuse.default_options as a starting point to build the options list, but that 2) these options are not usable "as is" for all thinkable scenarios.

then, if you have "foo" in default_options, the software needs to offer "nofoo" to the cli user to override that. if you have "nobar" in default_options, the software needs to offer "bar" to the user to override that.

of course the software needs to give the options to llfuse.init in the way so it has the right effect (so e.g. if "foo" is in options, "nofoo" would just remove it from the list. if "nobar" is in options, "bar" would remove it from there). of course this also depends what the real internal defaults are.

[ThomasWaldmann]

#4331 fixed 1.1-maint.

[ThomasWaldmann]

@LocutusOfBorg is it already too late or can this (borg 1.1.9) still get into next debian?

[LocutusOfBorg]

You mean the one that is already ongoing in unstable?
I guess it is fine, if it builds correctly and nobody reports regressions

[ThomasWaldmann]

as far as i could see on packages.debian.org, unstable (sid) has 1.1.8 still (1.1.9 is brand new, just released it).

[LocutusOfBorg]

https://packages.qa.debian.org/b/borgbackup/news/20190211T093407Z.html :)

[ThomasWaldmann]

• 1.0-maint: security fix: configure FUSE with "default_permissions", fixes #3903 #4355
• 1.1-maint: borg mount / borgfs security fix (1.1-maint) #4331 + part of Release 1.1.9 #4342 (this: 3841731 ) - released in 1.1.9
• master: security fix: configure FUSE with "default_permissions", fixes #3903 #4354 + test_mount_hardlinks: get rid of fakeroot-caused test fails, fixes #3389 #4347