20 ms·

I too have issues with this, but mainly trying to run protected ports (port 53 for DNS with PiHole) as rootless Podman -- it just did not work. Went back to doc

• candiddevmike 4y ago
  Just don't use rootless. You can still do user namespace containers (the real benefit to rootless, IMO) as a root user. I predict we will find all sorts of fun, niche security bugs that were made to get rootless containers working, especially networking--linux really doesn't like unprivileged changes to the networking stack. If you already have sudo/root access for your user, rootless is just going to cause more problems.
• mbreese 4y ago
  I think that’s by design. Non-root users aren’t supposed to be able to listen on protected ports. If you need to run PiHole as a non-root user, you could start the container rootless to listen on 5353/udp (arbitrary). Then (as root), add a firewall rule to redirect traffic from 5353/udp -> 53/udp. That probably the only way to make this work while still running the container as a non-root user.
  • yrro 4y ago
    There are two ways around this: Frist, you can run the container with --cap-add=net_bind_service which allows processes to bind to privileged ports: $ podman run --cap-add=net_bind_service --rm -it --user=1 localhost/socat bash-5.1$ id uid=1(bin) gid=1(bin) groups=1(bin) bash-5.1$ capsh --print Current: cap_net_bind_service=eip Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap Ambient set =cap_net_bind_service Current IAB: !cap_dac_read_search,!cap_linux_immutable,^cap_net_bind_service,!cap_net_broadcast,!cap_net_admin,!cap_net_raw,!cap_ipc_lock,!cap_ipc_owner,!cap_sys_module,!cap_sys_rawio,!cap_sys_ptrace,!cap_sys_pacct,!cap_sys_admin,!cap_sys_boot,!cap_sys_nice,!cap_sys_resource,!cap_sys_time,!cap_sys_tty_config,!cap_mknod,!cap_lease,!cap_audit_write,!cap_audit_control,!cap_mac_override,!cap_mac_admin,!cap_syslog,!cap_wake_alarm,!cap_block_suspend,!cap_audit_read,!cap_perfmon,!cap_bpf,!cap_checkpoint_restore Securebits: 00/0x0/1'b0 (no-new-privs=0) secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) secure-no-ambient-raise: no (unlocked) uid=1(bin) euid=1(bin) gid=1(bin) groups=1(bin) Guessed mode: UNCERTAIN (0) bash-5.1$ socat -dd - TCP-LISTEN:22 2023/02/21 09:19:34 socat[82] N reading from and writing to stdio 2023/02/21 09:19:34 socat[82] W ioctl(5, IOCTL_VM_SOCKETS_GET_LOCAL_CID, ...): Inappropriate ioctl for device 2023/02/21 09:19:34 socat[82] N listening on AF=2 0.0.0.0:22 Second, you can run the container with --sysctl=net.ipv4.ip_unprivileged_port_start=0 which tells the kernel to allow any process to bind to ports above 0 instead of the default of 1024: $ podman run --sysctl=net.ipv4.ip_unprivileged_port_start=0 --rm -it --user=1 registry.access.redhat.com/ubi9/ubi-minimal bash-5.1$ id uid=1(bin) gid=1(bin) groups=1(bin) bash-5.1$ socat -dd - TCP-LISTEN:22 2023/02/21 09:26:55 socat[59] N reading from and writing to stdio 2023/02/21 09:26:55 socat[59] W ioctl(5, IOCTL_VM_SOCKETS_GET_LOCAL_CID, ...): Inappropriate ioctl for device 2023/02/21 09:26:55 socat[59] N listening on AF=2 0.0.0.0:22
    • mbreese 4y ago
      That seems like a security issue if podman can do that without root access, yes? As in -- on a multi-user machine, this could be a problem.
      • yrro 4y ago
        This is only within the context of the pod's network namespace.
• PeterWhittaker 4y ago
  Start the container via systemd and ensure it has CAP_NET_BIND?