Skip to content

Remove chmod 777 in filesystem layer for rootless container compatibility - #3953

Open
karttikjangid wants to merge 1 commit into
JdeRobot:humble-develfrom
karttikjangid:fix/remove-chmod-777
Open

Remove chmod 777 in filesystem layer for rootless container compatibility#3953
karttikjangid wants to merge 1 commit into
JdeRobot:humble-develfrom
karttikjangid:fix/remove-chmod-777

Conversation

@karttikjangid

Copy link
Copy Markdown
Contributor

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.py successfully writes content to the filesystem but immediately attempts an explicit os.chmod(path, 0o777).

  1. Rootless incompatibility: In rootless container environments like Podman, modifying file permission bits on host bind-mounted volumes triggers an 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()) in manager.py, leaving orphaned Xvnc and websockify zombie processes holding onto port 6080.
  2. Unnecessary permissions: Tracing file access across the codebase confirmed that world-writable (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 (0o664 for files, 0o775 for 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 from filesystem/.

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

  • Rootless Podman validation: Started the container using podman-compose and entered an exercise (Follow Line). Verified that academy.py is created cleanly in /RoboticsAcademy/filesystem/ with standard permissions and without triggering backend exceptions.
  • UI & File Saving: Edited code in the browser and performed saves and exits. Confirmed the "Error saving file" modal is completely resolved and endpoints return 200 OK.
  • Disconnect & Cleanup testing: Performed hard browser tab refreshes (Ctrl+Shift+R) during active Gazebo simulation sessions. Checked terminal logs and container processes (ps -ef) to verify that save_file finishes cleanly on disconnect, allowing terminate_tools() to run to completion without leaving zombie VNC sessions or port conflicts on reconnection.

@karttikjangid
karttikjangid marked this pull request as ready for review August 20, 2026 17:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant