Remove chmod 777 in filesystem layer for rootless container compatibility - #3953
Open
karttikjangid wants to merge 1 commit into
Open
Remove chmod 777 in filesystem layer for rootless container compatibility#3953karttikjangid wants to merge 1 commit into
karttikjangid wants to merge 1 commit into
Conversation
karttikjangid
marked this pull request as ready for review
August 20, 2026 17:07
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
This PR is part of the ongoing work to migrate RoboticsAcademy from rootful Docker to rootless Podman as part of GSoC.
When running the platform under rootless Podman, saving workspace files or navigating back to the home screen resulted in an "Error saving file" popup in the UI and a 500 error in the backend.
Why This Changed
During file saving and directory creation,
file_access.pysuccessfully writes content to the filesystem but immediately attempts an explicitos.chmod(path, 0o777).EPERM(Permission denied) error from the Linux kernel. When this exception occurs during a browser tab refresh or exit, it interrupts the backend cleanup sequence (terminate_tools()) inmanager.py, leaving orphanedXvncandwebsockifyzombie processes holding onto port 6080.0o777) permissions are not architecturally required. The files stored under/RoboticsAcademy/filesystem/are managed exclusively by the Django API (views.py). Because Django is the creator of these files, standard system umask permissions (0o664for files,0o775for directories) inherently grant full read and write access. Furthermore, when running simulations, the browser transmits user code as a base64-encoded zip over WebSockets to RAM, which extracts and executes it in/workspace/code/. The simulation engine never reads code directly fromfilesystem/.Removing the 5 explicit
os.chmod(path, 0o777)calls eliminates a known security anti-pattern while maintaining complete backward compatibility with standard Docker setups (where the container runs as root and ignores file read/write permission restrictions).How We Tested It
podman-composeand entered an exercise (Follow Line). Verified thatacademy.pyis created cleanly in/RoboticsAcademy/filesystem/with standard permissions and without triggering backend exceptions.Ctrl+Shift+R) during active Gazebo simulation sessions. Checked terminal logs and container processes (ps -ef) to verify thatsave_filefinishes cleanly on disconnect, allowingterminate_tools()to run to completion without leaving zombie VNC sessions or port conflicts on reconnection.