procd/initd, branch master

initd: log if the noafile lock-down remount fails

2026-08-12T17:17:15Z

The final MS_REMOUNT | MS_RDONLY in early_noafile() was unchecked. A failure there leaves /tmp/.ujail silently read-write, so every jail then masks against a weaker, uid-mapping-dependent noafile with nothing logged anywhere. Signed-off-by: Joshua Covington

initd: provide a read-only noafile for ujail path masking

2026-08-12T09:03:11Z

ujail masks file paths such as /proc/kcore by bind-mounting a 0-byte mode-0000 file over them, so any access fails with an error instead of being silently swallowed the way a /dev/null bind would. Jails which defer their own user namespace re-apply these masks from inside the container; a mask source file created by the jail child itself is owned by the very host uid container root maps to, since the child runs with euid root_map_uid, and container root can therefore chmod or unlink it. Create a single canonical mask source at boot instead, right after mounting /tmp: a 0-byte mode-0000 file on a dedicated 4k tmpfs at /tmp/.ujail, remounted read-only at superblock level. The superblock belongs to the initial user namespace, so no user namespace can ever remount it read-write; chmod, unlink and write fail with EROFS through every path, including fresh bind mounts created from inside a container, and that holds even when host root is mapped into the container. Creating the file once during early boot also means jails starting in parallel never need a concurrent create-if-missing dance. Signed-off-by: Daniel Golle

initd: mount /sys and /proc with MS_RELATIME

2024-11-13T21:48:05Z

Despite access timestamps not being needed on /sys and /proc, using MS_NOATIME leads to many container tools not working because the new mounts of /proc or /sys are more revealing than the original ones. This results in not being able to mount /proc inside a user namespace with procd's uxc, but also other tools like bubblewrap, podman or lxd. Fix this by setting MS_RELATIME instead. The problem has been present in procd since commit 9fcc900 ("fix up the mount options to match what openwrt had before using procd as pid 1") but also in pre-procd OpenWrt releases. Signed-off-by: Daniel Golle

init: attempt to mount efivarfs

2023-01-16T21:07:54Z

Mount efivarfs to /sys/firmware/efi/efivars if available. Tested-by: Oskari Rauta Signed-off-by: Daniel Golle

init: only relabel rootfs if started from initramfs

2022-06-01T19:40:23Z

Do not relabel all the filesystem if not running from initramfs, it should only be needed in this case. Read-write (ext4) labels should be set when generating the filesystem just like it's done for squashfs. Signed-off-by: Daniel Golle

init: selinux: don't relabel virtual filesystems

2022-06-01T19:40:23Z

Attempting to relabel /dev/console, /proc or /sys results in an error message. Avoid that by excluding them when relabeling rootfs on boot. Signed-off-by: Daniel Golle

init: restore SELinux labels after policy is loaded

2022-05-03T01:05:16Z

Introduce an additional SELinux init step to calling restorecon to label the filesystem. This fixes SELinux on initramfs or systems with ext4 or ubifs read-write root filesystem. Signed-off-by: Daniel Golle

procd: completely remove tmp-on-zram support

2022-03-03T20:25:56Z

The configuration settings were removed from the package, this is now dead code. Signed-off-by: Rui Salvaterra

procd: clean up /dev/pts mounts

2022-01-11T16:23:25Z

The default mode is already 600, no need to specify it. Access times are also irrelevant. Signed-off-by: Rui Salvaterra

procd: mount /dev with noexec

2022-01-11T16:23:05Z

/dev is writable. Allowing execution inside it makes it a possible attack vector. Kees Cook recently sent a kernel patch [1] in order to mount /dev as noexec and nosuid for systems which rely on CONFIG_DEVTMPFS_MOUNT=y to create/populate /dev, which isn't our case (it's procd's responsibility). Add noexec to the /dev mount flags, since we already use nosuid (and keep the coldplug flags symmetric, while at it). This carries the risk of breaking very old, pre-KMS graphics drivers [2], but it shouldn't be a problem for systems built in the last ~15 years. The vast majority of our targets doesn't have a GPU, anyway. :) [1] https://lore.kernel.org/all/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/ [2] https://lore.kernel.org/all/CAPXgP12e5LpN6XVxaXOHhH=u8XXN==2reTaJDCoCk4tP4QduDQ@mail.gmail.com/ Signed-off-by: Rui Salvaterra