Hello everyone,
I'm a hobbyist running a container build pipeline on **Debian GNU/Linux 12 (Bookworm) / Raspberry Pi OS**. I am new to Linux security and have been troubleshooting this complex, low-level issue with an AI assistant (Gemini). **My constraint is that I often have to stop work for months at a time, making complex, multi-step debugging difficult.** I would like a stable fix, not a temporary workaround. I had gemini write this because I alway had trouble with my spelling and not including the need info I do the best I can to give you all the info you need and to resolve this problem on my own. I just editing it a little to include what I want to say a little better.
**My Goal:** Build a container base image from `scratch` using `debootstrap` while running **Buildah rootless** (as user `pi`, UID 1000).
###![💥]()
The Consistent Failure
My script fails when attempting to create device nodes (`mknod`) inside the container's mounted root filesystem:
**Error Output:**
```
mknod: /path/to/container/merged/dev/null: Operation not permitted
E: Cannot install into target '...' mounted with noexec or nodev
```
###![🔬]()
The Technical Diagnosis & Attempts to Fix AppArmor
The issue is the host kernel's security configuration, which blocks the `CAP_MKNOD` capability needed for this process.
1. **Broken AppArmor State:** The AppArmor kernel module is loaded, but the service is dead. I tried to correct this by remounting and creating the control directory, but the parent directory blocks all attempts.
2. **The Unmovable Blocker:** The required mount point is sealed off by the parent `securityfs` mount:
```
securityfs on /sys/kernel/security type securityfs (rw,nosuid,**nodev**,noexec,relatime)
```
The **`nodev`** flag on `/sys/kernel/security` makes it impossible to successfully create the required subdirectory (`/sys/kernel/security/apparmor`) or remount to enable device creation, even with `sudo`.
###![❓]()
Key Questions for Bookworm/RPi Experts
1. **Verification:** Is the **`nodev`** flag on the **`securityfs`** mount the definitive reason why my rootless Buildah process cannot use `mknod`?
2. **AppArmor Fix:** What is the **correct, documented, and maintainable method on Debian 12 (Bookworm)** to either:
* **A) Successfully mount the AppArmor control filesystem** to allow policy management (despite the existing `securityfs nodev` constraint)?
* **B) Permanently remove the `nodev` restriction** on the `/sys/kernel/security` mount via a system configuration file (like a kernel parameter or fstab entry)?
3. **Alternative Security Module:** Given the difficulty with AppArmor, **would enabling another security module (like SELinux or setting specific `unshare` flags) provide a cleaner path** to grant the required `CAP_MKNOD` capability for rootless builds on RPi OS?
Thank you for any guidance. I need a solution that is robust enough to last through long periods of inactivity\!
I'm a hobbyist running a container build pipeline on **Debian GNU/Linux 12 (Bookworm) / Raspberry Pi OS**. I am new to Linux security and have been troubleshooting this complex, low-level issue with an AI assistant (Gemini). **My constraint is that I often have to stop work for months at a time, making complex, multi-step debugging difficult.** I would like a stable fix, not a temporary workaround. I had gemini write this because I alway had trouble with my spelling and not including the need info I do the best I can to give you all the info you need and to resolve this problem on my own. I just editing it a little to include what I want to say a little better.
**My Goal:** Build a container base image from `scratch` using `debootstrap` while running **Buildah rootless** (as user `pi`, UID 1000).
###
The Consistent FailureMy script fails when attempting to create device nodes (`mknod`) inside the container's mounted root filesystem:
**Error Output:**
```
mknod: /path/to/container/merged/dev/null: Operation not permitted
E: Cannot install into target '...' mounted with noexec or nodev
```
###
The Technical Diagnosis & Attempts to Fix AppArmorThe issue is the host kernel's security configuration, which blocks the `CAP_MKNOD` capability needed for this process.
1. **Broken AppArmor State:** The AppArmor kernel module is loaded, but the service is dead. I tried to correct this by remounting and creating the control directory, but the parent directory blocks all attempts.
2. **The Unmovable Blocker:** The required mount point is sealed off by the parent `securityfs` mount:
```
securityfs on /sys/kernel/security type securityfs (rw,nosuid,**nodev**,noexec,relatime)
```
The **`nodev`** flag on `/sys/kernel/security` makes it impossible to successfully create the required subdirectory (`/sys/kernel/security/apparmor`) or remount to enable device creation, even with `sudo`.
###
Key Questions for Bookworm/RPi Experts1. **Verification:** Is the **`nodev`** flag on the **`securityfs`** mount the definitive reason why my rootless Buildah process cannot use `mknod`?
2. **AppArmor Fix:** What is the **correct, documented, and maintainable method on Debian 12 (Bookworm)** to either:
* **A) Successfully mount the AppArmor control filesystem** to allow policy management (despite the existing `securityfs nodev` constraint)?
* **B) Permanently remove the `nodev` restriction** on the `/sys/kernel/security` mount via a system configuration file (like a kernel parameter or fstab entry)?
3. **Alternative Security Module:** Given the difficulty with AppArmor, **would enabling another security module (like SELinux or setting specific `unshare` flags) provide a cleaner path** to grant the required `CAP_MKNOD` capability for rootless builds on RPi OS?
Thank you for any guidance. I need a solution that is robust enough to last through long periods of inactivity\!
Statistics: Posted by frog-o — Wed Dec 03, 2025 10:07 am