12 days ago
Hello Railway team,
I am qualifying an anti-rollback trust-anchor design on a Railway persistent volume.
The application container is intentionally non-privileged. The runtime runs as UID 65534 with CapEff=0 and therefore cannot remove Linux append-only protection.
During provisioning, however, even UID 0 inside the Railway container cannot set FS_APPEND_FL on a file located on the mounted persistent volume:
FS_IOC_SETFLAGS -> EPERM
The inode remains without FS_APPEND_FL.
We specifically do not want to grant CAP_LINUX_IMMUTABLE to the application container, because that would allow the runtime to remove the protection and defeat the security property.
Is there a Railway-supported mechanism to:
- provision a file on a persistent Railway volume with FS_APPEND_FL set from the host/provider side;
- keep that flag persistent across deployments/restarts;
- expose the file to the application container while the application remains unable to clear the flag;
- preserve the flag across Railway volume backup/restore operations?
The desired security model is:
provider/admin can provision append-only inode -> unprivileged application can append -> application cannot clear append-only flag.
If Railway persistent volumes do not support this model, could you confirm that explicitly?
No privileged container, Docker-in-Docker, host access, or capability escalation is required or desired.
Thank you.
1 Replies
12 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 12 days ago
12 days ago
volumes do not support this, as setting FS_APPEND_FL requires CAP_LINUX_IMMUTABLE, which isn't granted by default with docker and railway doesn't let you add capabilities. also, a project administrator can always detach, restore or swap the volume, so the security model doesn't really work. if you are worried about being able to modify the volume, you would need to run an external S3 instance and use something like compliance mode