Не могу установить пакет, вываливается с ошибкой.

А ты его что в докер ставишь?

Нет, напрямую в свою систему.

Добавь своего пользователя в группу wireshark и перелогинься. Должно полегчать. Ну или запусти от рута

Да нифига. Давно сделано:

:~> id
uid=1000(viktor) gid=100(users) группы=100(users),442(libvirtdbus),459(vboxusers),460(libvirt),461(qemu),463(wireshark),470(pulse-access),471(pulse),483(video),487(kvm),489(disk),490(dialout),491(cdrom)

Перелогинелся?

естественно

Запускай от рута. Если от него работает, то копай дальше на тему прав. Если нет, значит в зюзе накосячили и лучше перекатиться на арчик.

Гражданин, вы не поняли - я не запустить не могу. Я установить не могу. В момент установки пакета вываливается ошибка. Какая-то лажа с capabilities.

Тю. Я то думал серьёзная проблема. А тут всего лишь нужно перекатиться на арчик.

Я, конечно, поддерживаю радикальные методы отечественной медицины. Кровь носом? - жгут на шею. Головная боль? - лоботомия.

Но мне бы попробовать полечить. Может ещё поживёт.

Дай вывод команды mount. В интернетах пишут, что такая ошибка, если программу с suid битом хочешь скопировать на раздел смонтированный с параметром nosuid. Wireshark наверное через suid бит себе привилегии получает.

:~> sudo mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=4096k,nr_inodes=1048576,mode=755,inode64)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=13148892k,nr_inodes=819200,mode=755,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p2 on / type ext4 (rw,noatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19525)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
/dev/sdb1 on /mnt/Data type ext4 (rw,noatime)
/dev/sdc1 on /mnt/VMs type ext4 (rw,noatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sda1 on /home type ext4 (rw,noatime)
tmpfs on /run/user/466 type tmpfs (rw,nosuid,nodev,relatime,size=6574444k,nr_inodes=1643611,mode=700,uid=466,gid=466,inode64)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=6574444k,nr_inodes=1643611,mode=700,uid=1000,gid=100,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)

Ну я основной корень на разделы не делил. И nosuid точно никуда не выставлял. Да и suid’ных бинарников есть. Тот же mount: -rwsr-xr-x 1 root root 47408 Aug 31 19:16 mount

хотя вот весь этот фарш из tmpfs, tracefs и прочего непотребства наводит на мысли. Пошёл читать

Блин, не прокатило. А какая красивая теория была, согласись. Значит арчик 😏

установщик от рута запускаешь?

Система - OpenSuse Tumbleweed.

Она установлена на физическом сервере или где?

Естественно от рута. Установлена на физической машине.

error: unpacking of archive failed on file /usr/bin/dumpcap;634071a0: cpio: cap_set_file failed - Operation not permitted

Вот конкретно эта ошибка означает, что у запущеного процесса cpio нет права ставить capabilities только что распакованному /usr/bin/dumpcap.

capabilities может ставить либо рут (кому угодно), либо кто-то с правом CAP_SETFCAP (только своим файлам), либо кто-то с правом CAP_SETFCAP+CAP_FOWNER (всем).

Поскольку записывать файл в /usr/bin кроме рута вряд ли кто-то может (или может? посмотри какие там owner/group), то крайне странно что при этом запрещён setcap, наводит на мысли что это всё-таки не физический сервер а контейнер в нём. Проверь команду setcap (не пишет ли ошибки):

touch /root/test.bin
chmod +x /root/test.bin
setcap cap_net_raw,cap_net_admin,cap_dac_override+eip /root/test.bin
getcap /root/test.bin

Или может у тебя какая-то странная файловая система в /usr и она не поддерживает capabilities? Если пример выше сработает без ошибок, в /usr у тебя смонтирован отдельно - проверь то же самое и на файле /usr/bin.

Посмотрел права на /usr/bin и нифига не понял. Как?:

ll -d /usr/bin/
dr-xr-xr-x 2 root root 233472 Oct  8 13:06 /usr/bin/

При этом я только что поставил обновления которые без проблем поставились, включая пакеты содержимое которых писалось в /usr/bin.

UPD - добавление права на запись root’у в /usr/bin не помогло.

setcap вывалился с ошибкой:

setcap cap_net_raw,cap_net_admin,cap_dac_override+eip /root/test.bin
Failed to set capabilities on file '/root/test.bin': Operation not permitted

/usr не смонтирован отдельно. Файловая система ext4:

df -Th /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p2 ext4  219G   31G  178G  15% /

Право на запись руту тут не важно, рут эти права игнорирует всё равно. Было подозрение, что оно какое-нить root:operator и право на запись группе, тогда установщик мог не от рута работать и понятно было бы откуда проблема.

setcap вывалился с ошибкой:

А вот и причина виднеется, но надо выяснить почему оно так.

А если так:

setcap cap_net_admin+eip /root/test.bin

и getcap проверь отдельно в любом случае

setcap вывалился с ошибкой:

setcap cap_net_admin+eip /root/test.bin
Failed to set capabilities on file '/root/test.bin': Operation not permitted

getcap отрабатывает молча, ничего не выводя.

Ну тут причины могут быть такие

1) у тебя кастомное ядро без поддержки capabilities

2) ты таки в контейнере но почему-то об этом не знаешь (ты точно всё это на физическом компе запускаешь, ну к нему монитор подключён напрямую итд, и ты в нативной консоли которая в текстовом режиме залогинился за рута?)

3) какой-нить selinux запрещает setcap

4) у тебя на компе действует какой-то незапланированный функционал (вирусы например)

1. ядро из реп
2. не ну я ж не дебил. Я сижу сейчас за этим компом, смотрю фильмец, консолька, все дела, гамесы с сыном гоняем.
3. selinux снесён как первый подозреваемый.
4. какой-то интересный был бы вирус - не устанавливается только wireshark. Все остальные пакеты ставятся, обновляются.

Ну я думаю ты из гуи открываешь консоль, мало ли что там в DE накрутили. Попробобуй ctrl-alt-f2 и там за рута залогиниться и setcap проверить.

И дело не в wireshark а именно в capabilities. Wireshark просто единственный кому они нужны оказались.

Ещё можно getcap /bin/ping попробовать, обычно на нём cap_net_raw присутствует, если capabilities вообще есть (раньше его suid-root делали а теперь он без suid но с cap_net_raw)

Не, в консоли то же самое. getcap /usr/bin/ping ничего не выдаёт. При этом suid на нём не установлен.

И при этом пинг не от рута работает?

Да

А если сделать cp /usr/bin/ping /usr/local/bin/ping и запустить не от рута этот скопированный пинг то он уже не работает?

Работает:

/usr/bin/ping_z 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=0.909 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=1.26 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=0.838 ms

Это не рутом? А если копировать тоже не рутом?

Первый раз копировал рутом, запускал не рутом.

Второй раз копировал не рутом в директорию /usr/bin/ - скопировать не дало. Отказано в доступе.

Скопировал /usr/bin/ping в /home/user/bin. Запускается без проблем:

cp /usr/bin/ping bin/ping_z
bin/ping_z 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=0.956 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=0.932 ms
^C

Ну так не должно быть, без рута и без cap_net_raw прав отправлять пинги нет. А при копировании, тем более обычным юзером, шансов установить что-то из этого на новый бинарник нет (не говоря уж о том что setcap у тебя сломан).

Не знаю что это, но у тебя что-то совсем неправильное с capabilities - их с одной стороны невозможно установить, а с другой некоторые из них как будто включены для всех сразу, что есть явная дыра в безопасности. Если б они были отключены в ядре - пинг бы не работал.

Не знаю, может ли это быть какой-то сложный баг, но я бы подозревал руткит который это всё использует для маскировки. Попробуй с livecd загрузиться и проверить getcap на всё что надо и вообще посмотреть что там в файловой системе происходит, может что неожиданное увидишь.

сходу не подскажешь какие флаги могут отвечать за capabilities в sysctl? Посмотрю сначала там, потом пойду ковырять на тему руткитов.

Спасибо за посильную помощь.

У меня такое только нашлось

sysctl -a | grep cap
kernel.cap_last_cap = 40

У меня аналогичный результат. Пошёл искать гадов в системе.