2 ms·

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

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.

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.