-
Notifications
You must be signed in to change notification settings - Fork 79
Open
Labels
Description
Proposed Change
As an app developer
I want to mount FUSE filesystems from within my app instance without any special privileges
So that I can fill gaps using existing FUSE solutions.
- Disk capacity is a limiting factor for many jobs that might otherwise run well in CF. Given the
efs-volume-releaseis mothballed, andnfs-volume-releaseis tricky to operate, operator support for persistent or large filesystems may not be available. - App developers might have various network block/blob or other file storage options available to them via FUSE, but (previously!) they had no ability to use them because FUSE required
CAP_SYS_ADMIN, which garden-runc explicitly strips. - This situation has changed! See below.
Acceptance criteria
Scenario:
Given I have deployed an application
And the application includes sshfs
And I have started a shell inside the container (eg via cf ssh)
When I run unshare -c --keep-caps -m
And I run mkdir dirname; sshfs user@host:dirname dirname (for an available user@host)
Then the command succeeds
And I see the content of user@host:dirname under dirname.
Related links
- In August 2018, FUSE stopped requiring
CAP_SYS_ADMIN. - Since at least 2020, it's been possible to mount FUSE filesystems from within a Docker container without
--privilegedor--cap-add SYS_ADMIN.- Guardian already makes
/dev/fuseavailable in containers, so I suspect that enabling this may just be a case of the seccomp profile provided to runC growing the additions forclone,mount,umount,umount2, andunshare.
- Guardian already makes
- More recently, FUSE Passthrough Mode landed in kernel 6.9, which is likely to alleviate operator concerns about the potential for CF apps using FUSE to swamp hosts with CPU load.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Inbox