Regression - rclone with fusermount

[Daviey]

Name and Version

bitnami/rclone:1

What architecture are you using?

None

What steps will reproduce the bug?

Use rclone with fuse, which was functional and introduced with https://github.com/bitnami/containers/pull/50118

Seeing this error in rclone:

2024/02/09 15:23:21 mount helper error: fusermount3: mount failed: Operation not permitted
2024/02/09 15:23:21 Fatal error: failed to mount FUSE fs: fusermount: exit status 1

What is the expected behavior?

No error

What do you see instead?

Error

Additional information

Appears it was introduced with this (undocumented change?). Removing this line resolves the issue: https://github.com/bitnami/containers/commit/fe6275ac1df27da71da03d734e4afddacac24a47

[Mauraza]

Hi @Daviey,

Could you tell us how you are running the fuse? Have you tried as root?

[Daviey]

The change I linked to shows that the setuid bit is stripped from all files, and it is needed for /bin/fusermount3, which rclone is executing itself.

The change added this: RUN find / -perm /6000 -type f -exec chmod a-s {} \; || true

My docker command is: rclone mount union: /storage --config=/tmp/rclone.conf

I can confirm running with -u root does work around the issue, but I don't think it is the right fix for the issue. May I suggest that /bin/fusermount3 is excluded from stripped setuid, because that binary really needs it.

[Mauraza]

Hi @Daviey,

That change is related to DISA CIS security that executables inside the container should not have the setgid setuid enabled.

[Daviey]

@Mauraza

I get the reasoning, but this seemingly undocumented changed has introduced a regression.

To quote CIS Docker benchmark on this issue:

Rationale:
setuid and setgid permissions can be used for privilege escalation. Whilst these
permissions can on occasion be legitimately needed, you should consider removing
them from packages which do not need them. This should be reviewed for each image.

Impact:
The above command would break all executables that depend on setuid or setgid
permissions including legitimate ones. You should therefore be careful to modify the
command to suit your requirements so that it does not reduce the permissions of
legitimate programs excessively. Because of this, you should exercise a degree of
caution and examine all processes carefully before making this type of modification in
order to avoid outages.

Based on that, the Rationale and Impact does make it clear that breaking functionality like this shouldn't introduce regressions like this.

In regards to DISA, are you referencing the DISA Docker Enterprise STIG, or something else?

[Mauraza]

Hi @Daviey,

Yes, it is for STIG. We think the user should be able to execute fusermount, so I will open it to change it. We will update this issue with more information.