MikroTik Solutions

Changes To Container Limitations
Login

Changes To Container Limitations

Changes to "Container Limitations" between 2024-08-10 14:48:19 and 2024-08-10 15:33:33

186
187
188
189
190
191
192
193



194
195
196
197
198
199
200
186
187
188
189
190
191
192

193
194
195
196
197
198
199
200
201
202







-
+
+
+







(The same is true of `podman logs`, except that it ties into systemd’s unified “journal” subsystem, a controversial design choice that ended up paying off handsomely when Podman came along and wanted to pull up per-container logs to match the way Docker behaved.)


# <a id="root"></a>Everything Is Rootful

This shows up in a number of guises, but the overall effect is that all containers run as a nerfed `root` user under `container.npk`, same as Docker did from the start. This remains the Docker default, but starting with the 20.10 release, it finally got a [rootless mode][drl] to compete with [Podman’s rootless-by-default][prl] nature. I bring up this history to show that RouterOS is not unconditionally “wrong” to operate as it does, merely limited.

This design choice may be made reasonably safe through the grace of user namespaces — “userns” in kernel-speak — which cause the in-container `root` user to be meaningfully different from the Linux `root` user that RouterOS itself runs as. RouterOS has a `/user` model, but they are not proper Linux users as understood by the kernel, with permissions enforced by Linux user IDs. This means that when you start a container as RouterOS user `fred`, you do not see a `fred` user inside the container, and that files created by that nerfed `root` user show up as owned by `root` when using bind-mounted directories on file systems like `ext4` which preserve file ownership.
This design choice may be made reasonably safe through the grace of user namespaces — “userns” in kernel-speak — which cause the in-container `root` user to be meaningfully different from the Linux `root` user that RouterOS itself runs as. RouterOS does have a `/user` model, but they are not proper Linux users as understood by the kernel, with permissions enforced by Linux user IDs, which means they have no existence inside the container. One practical effect of this is that when you start a container as RouterOS user `fred`, you will not find a `fred` entry in its `/etc/passwd` file, and if you create one at container build time (e.g. with a `RUN useradd` command) it will not be the same `fred` as the RouterOS user on the outside.

Files created by that nerfed `root` user will show up as owned by `root` when using bind-mounted directories on file systems like `ext4` which preserve file ownership.

That yields one possible solution for this:

    /disk/format-drive file-system=exfat …

It is because of this same limitation that there is no RouterOS equivalent to the `create --user*` or `--group-add` flags.