Cron doesnt work when namespaces is enabled on host[BUG]

[budbay]

Describe the bug I have namespaces enabled for docker but disabled for this container with userns_mode: host since smartmontools cant access devices with it enabled. Now cron doesn't trigger the collector because inside the container the scrutiny cron file is not owned by root:

root@scrutiny:/opt/scrutiny# cd /etc/cron.d
root@scrutiny:/etc/cron.d# ls -la
total 24
drwxr-xr-x 1 100000 100000 4096 Feb 12 11:42 .
drwxr-xr-x 1 100000 100000 4096 Feb 12 11:42 ..
-rw-r--r-- 1 100000 100000  102 Feb 22  2021 .placeholder
-rw-r--r-- 1 100000 100000  201 Jun  7  2021 e2scrub_all
-rw-r--r-- 1 100000 100000  838 Feb 12 11:42 scrutiny

if i manually chown scrutiny to root inside the container, cron starts working. However, once the container is updated or restarted, the file is back to old ownership.

Expected behavior Cron files are owned by root

Screenshots n/a

Log Files n/a

Docker Info

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 69
  Running: 66
  Paused: 0
  Stopped: 3
 Images: 61
 Server Version: 23.0.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: syslog
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 31aa4358a36870b21a992d3ad2bef29e1d693bec
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  userns
  cgroupns
 Kernel Version: 5.15.0-60-generic
 Operating System: Ubuntu 22.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.34GiB
 Name: hostname
 ID: id1234
 Docker Root Dir: /media/100000.100000
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: true
 Default Address Pools:
   Base: 172.17.0.0/12, Size: 20
   Base: 10.17.0.0/16, Size: 24

[martadinata666]

I'm looking on docker docs about userns here, tldr: even userns disable the layer still remapped.

Disable namespace remapping for a container

If you enable user namespaces on the daemon, all containers are started with user namespaces enabled by default. In some situations, such as privileged containers, you may need to disable user namespaces for a specific container. See user namespace known limitations for some of these limitations.

To disable user namespaces for a specific container, add the --userns=host flag to the docker container create, docker container run, or docker container exec command.

There is a side effect when using this flag: user remapping will not be enabled for that container but, because the read-only (image) layers are shared between containers, ownership of the containers filesystem will still be remapped.

What this means is that the whole container filesystem will belong to the user specified in the --userns-remap daemon config (231072 in the example above). This can lead to unexpected behavior of programs inside the container. For instance sudo (which checks that its binaries belong to user 0) or binaries with a setuid flag.

Specifically this part

• There is a side effect when using this flag: user remapping will not be enabled for that container but, because the read-only (image) layers are shared between containers, ownership of the containers filesystem will still be remapped.

• What this means is that the whole container filesystem will belong to the user specified in the --userns-remap daemon config (231072 in the example above). This can lead to unexpected behavior of programs inside the container. For instance sudo (which checks that its binaries belong to user 0) or binaries with a setuid flag.

[techwiz2100]

Just wanted to drop in and leave some more info to help debug these cron issues... I entered the docker container running scrutiny and noticed that crontab reported that there wasn't one for root. I had to manually load the crontab for root by doing crontab /etc/crontab and then crontab reported correctly. Maybe the dockerfile needs another command to reinstall the crontab on startup.

I do not see any permissions issues, so I might not be seeing the exact same issue reported here.