Forum

AI Assistant
Notifications
Clear all

Error: 'Permission denied' when trying to write to a tmpfs volume I mounted.

1 Posts
1 Users
0 Reactions
0 Views
(@hobbyist_hardener_max)
Eminent Member
Joined: 2 weeks ago
Posts: 20
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1643]

Hey everyone,

Ran into a classic one while hardening a NanoClaw deployment on IronClaw 4.2. I've mounted a `tmpfs` volume for a container's temporary data, aiming to isolate it from the host filesystem. The mount itself works, but the application inside the container throws a `Permission denied` when trying to write to it.

Here's the relevant snippet from my Ansible task for the mount:

```yaml
- name: Mount tmpfs for secure scratch space
ansible.posix.mount:
path: /opt/nanoclaw/secure_tmp
src: tmpfs
fstype: tmpfs
opts: "nosuid,nodev,noexec,size=256M"
state: mounted
```

The directory `/opt/nanoclaw/secure_tmp` is created by the playbook with `0750` permissions, owned by `root:root`. The container runtime (we're using `containerd` with `crun`) is configured to map the container's internal user (`appuser`, UID 1001) to the host's same UID.

My hypothesis: It's a classic mismatch between the host directory ownership and the container user's UID, even though they're numerically the same. The `noexec` and `nodev` are fine, but the kernel might be checking the host-side ownership before the container user is even considered.

**What I've tried:**
* Confirmed UID 1001 exists on the host (it's a system user for the service).
* Changed the mount point's ownership to `1001:1001` on the host → writes work, but this feels wrong from a host hardening perspective.
* Tried adding `uid=1001,gid=1001` to the `opts` of the tmpfs mount → this actually solved it! But I'm not sure if it's the *correct* hardening approach.

My main question: **What's the most secure way to allow a specific container user to write to a host-mounted `tmpfs`?**

Should we:
1. Set the `uid/gid` in the tmpfs mount options (seems clean, confines it to the mount)?
2. Create a dedicated user namespace for the container and map UIDs accordingly (more complex, but more isolated)?
3. Something else with `podman`/`crun` security flags I'm missing?

I want to keep the host's `root` ownership of the mount point directory itself for audit trails. Sharing config diffs and `ls -laZ` output below.

- Max


Hardening is a hobby, not a job.


   
Quote