Ping with unprivileged user in LXC container / Linux capabilities

[onlime]

On Proxmox VE 5.1, inside an LXC container, I cannot ping with unprivileged user. It gives me the following error:

$ ping google.ch
ping: socket: Operation not permitted

On the hostnode itself I can ping with both unprivileged user and root, but inside an LXC container only as root.

The following fixes it and gives all unprivileged users the required privileges to a open the socket:

$ sudo setcap cap_net_raw+p /bin/ping

Here's my question:
Would that be the right solution without exposing too many privileges?
How come this has suddenly changed? I remember ping was always available to all system users, at least in the pre LXC 2.1 days.

 

[wbumiller]

This does not really depend on whether the container is privileged or not (or at least it shouldn't, otherwise there's some other issue involved). What distribution are you running in the container and which template? Most distros actually simply make `ping` setuid-root, which should work in containers as well. Some set capabilities like you posted above. However, sometimes they can get lost (eg. when you backup in suspend mode with NFS as a temp directory some file settings get lost due to them not being supported by NFS), and this will take effect when you restore such a backup.

 

[onlime]

Thanks for your hints. I am using 100% Debian Stretch in all LXC containers, all running on Proxmox VE 5.1 host nodes. It was quite weird as half of the containers had the cap_net_raw+ep capabilities set on /bin/ping, the other half were missing it. Also on Proxmox host nodes, only half of the systems had this capability set. None of them were using setuid bit, as e.g. Ubuntu 17.10 still does.

I am not using any NFS, only syncing LXC containers via ZFS send|receive (using zrep). Most of the containers were upgraded from Debian Jessie to Stretch a while ago. But both upgraded and set-up-from-scratch Debian Stretch containers were missing capabilities, completely random.

Can you please just tell me if a new Proxmox VE 5.1 host system applies cap_net_raw+ep to /bin/ping ? It seems like all newly set up PVE's were missing the capabilities.

 

[wbumiller]

Seems to be missing indeed after installing from the ISO. We'll need to fix this.

 

[uno]

I confirm that this still occurs in PVE 5.3. I ran the following to fix it.

setcap cap_net_raw+p /bin/ping

 

[oguz]

I confirm that this still occurs in PVE 5.3. I ran the following to fix it.

Which template?

 

[uno]

Sorry I forgot to mention. The "/bin/ping" in PVE 5.3 itself doesn't permit a regular user to run it. It worked after I ran "setcap"

 

[oguz]

Sorry I forgot to mention. The "/bin/ping" in PVE 5.3 itself doesn't permit a regular user to run it. It worked after I ran "setcap"

Looks like an upstream debian bug with squashfs-tools which in turn affects our installer. Thanks for reporting, we'll look into it.

 

[alatteri]

CentOS 8 LXC has this issue too.

 

[rechena]

This is still happening with Debian 10 template

 

[oguz]

This is still happening with Debian 10 template

it's working here with a clean debian 10 template.

* which template are you using?

* what is output of pveversion -v

 

[rechena]

Hi, thanks for the reply, I'm using the clean template.

* debian-10.3.0-amd64-netinst.iso

pveversion -v
proxmox-ve: 6.1-2 (running kernel: 5.3.18-2-pve)
pve-manager: 6.1-7 (running version: 6.1-7/13e58d5e)
pve-kernel-helper: 6.1-6
pve-kernel-5.3: 6.1-5
pve-kernel-5.3.18-2-pve: 5.3.18-2
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.3-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.15-pve1
libpve-access-control: 6.0-6
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.0-13
libpve-guest-common-perl: 3.0-3
libpve-http-server-perl: 3.0-4
libpve-storage-perl: 6.1-5
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-3
pve-cluster: 6.1-4
pve-container: 3.0-21
pve-docs: 6.1-6
pve-edk2-firmware: 2.20200229-1
pve-firewall: 4.0-10
pve-firmware: 3.0-6
pve-ha-manager: 3.0-8
pve-i18n: 2.0-4
pve-qemu-kvm: 4.1.1-3
pve-xtermjs: 4.3.0-1
qemu-server: 6.1-6
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.3-pve1

 

[oguz]

Hi, thanks for the reply, I'm using the clean template.

* debian-10.3.0-amd64-netinst.iso

this is not a CT, it's a VM...

try using the setcap command mentioned in the thread

 

[rechena]

this is not a CT, it's a VM...

try using the setcap command mentioned in the thread

Sorry my bad, I'm using the debian-10.0-standard_10.0-1_amd64.tar.gz

 

[oguz]

Sorry my bad, I'm using the debian-10.0-standard_10.0-1_amd64.tar.gz

just tried it and it works normally here.

ping command gives you permission denied?

what is the output of pct config CTID

 

[rechena]

Humm,

pct config CTID
-bash: pct: command not found

 

[oguz]

Humm,

pct config CTID
-bash: pct: command not found

are you running this in the container or on PVE? it needs to be run on PVE

 

[rechena]

Ok so I've just ran that command from two of my containers, and weirdly enough on 3 of the ones I tested I can't ping, but on another I can...

The one I CAN'T ping from:

root@sauron:~# pct config 507
arch: amd64
cores: 2
hostname: lxc-ansible01
memory: 2048
nameserver: 192.168.193.111
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.193.1,hwaddr=56:FF:42:28:71:D9,ip=192.168.193.200/24,type=veth
onboot: 1
ostype: debian
rootfs: SauronVMs:subvol-507-disk-1,size=10G
searchdomain: 192.168.193.110
swap: 512
unprivileged: 1

The one I CAN ping from:

root@sauron:~# pct config 503
arch: amd64
cores: 2
hostname: lxc-logstash01
memory: 4096
nameserver: 192.168.193.111
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.193.1,hwaddr=E6:6F:FA:79:8E:DE,ip=192.168.193.106/24,type=veth
onboot: 1
ostype: debian
rootfs: SauronVMs:subvol-503-disk-0,size=10G
searchdomain: 192.168.193.110
swap: 512
unprivileged: 1

 

[oguz]

but what do you get when you try to ping? please post output

 

[rechena]

but what do you get when you try to ping? please post output

$ ping 8.8.8.8
ping: socket: Operation not permitted