These two functions look at the global mount table. So they might fail if two tests are running in parallel. To fix that, you must mark the tests as exclusive. Or better yet, change these functions to they only look at a known mount point, with a command like df -T mnt.

I suggest unmount -f.

Using killall will also interfere with running tests in parallel. Is there anyway to kill by PID instead?

Instead of hard-coding a 1-second sleep, could you put a polling loop around df -T mnt?

Instead of su -m nobody below, can you set require.user unprivileged here?

Is this part forbidden even if vfs.usermount=1 ? If not, then you should skip the test if that setting is true.

It would be very bad to do this in the cleanup if that setting wasn't in use system-wide before the test started.

"could not" is past tense, and doesn't make sense here. Use "may not", "should not", or something like that.

Technically, this is a TOCTOU. You check the value of the sysctl here, but it might change before you mount or unmount anything later on. However, I don't think it will do damage. AFAICT the worst that will happen is that mount_fusefs -u might fail to unmount a mountpoint, if vfs.umount transitioned from 1 to 0 while the program was executing.

This is another TOCTOU. You stat the mountpoint on line 407, but don't use that information until line 418. The mountpoint may have changed in the meantime. I think the only safe way to do an operation like this would be to either do the permission check in the kernel, or implement some kind of unmountat syscall.

This TOCTOU is exploitable, too. For example:

• mkdir /tmp/mymountpoint
• ln -s /tmp/mymountpoint /tmp/mymountlink
• fuse-hello_ll /tmp/mymountpoint
• mount_fusefs -u /tmp/mymountpoint
  • statfs follows the symlink and returns information about /tmp/mymountpoint
  • after statfs returns, the user does ln -s / /tmp/mymountlink
• The checks pass, so mount_fusefs calls restore_privs, and then proceeds to unmount / with root privileges.

Another TOCTOU here. check_perm works by pathname, and it follows symlinks. So an attacker could create a symlink pointing to a directory that will satisfy the checks in check_perm. Then, after check_perm succeeds, he replaces that symlink with one point to somewhere else. Then the following nmount call will mount over top of that.

Using nocover and emptydir helps, by preventing the attacker from overwriting /etc. But those aren't good enough. For example, the attacker could use this method to mount over /usr/local/etc/some_daemon/ , if that directory were previously empty, providing his own config file for some_daemon.

Disabling allow_other and allow_root helps a lot. But it would still be possible for an attacker to replace a directory that should be empty with one that returns EPERM on access. So I'm still nervous.

You should document -o auto_unmount here, and maybe -u too.

If dounmount fails, you should restore mnt_cred->cr_uid

Should we restrict the ability to set user_id to privileged processes?

You can simplify this expression.

You need to sleep within the loop, not after it.

And simplify here too.

You need to sleep within the loop, not after it.

Trying to check the existence of $pid after killing it is unreliable. The pid might still exist even though you killed if either:

• It hasn't been reaped yet, or
• A new process has been spawned with that same pid.

If you think it's worth the effort, you could eliminate the special MOUNT_FUSEFS_TESTING code by using tarfs in this test.

If it's going to change global settings, it had better be exclusive.

If it's going to change global settings, it had better be exclusive.

You can delete this line, because it's redundant with the cleanup.