Pergunta

Adicionar CAP_SYS_ADMINainda é a única maneira de fazer o fuse funcionar dentro de um contêiner sem raiz (com sobreposição nativa ou fuse-overlayfs/outros métodos)?

Exemplos

Podman em podman

Este exemplo de https://www.redhat.com/en/blog/podman-inside-container

podman run --user podman --security-opt label=disable --device /dev/fuse -ti quay.io/podman/stable podman run -ti docker.io/busybox echo hello

funciona para mim sem problemas. Mas me faz supor que está usando fusermountdentro do contêiner ou que é possível usá-lo, o que não funciona quando se usa a mesma configuração.

Além do mais, parece não montar nada:

podman run --user podman --security-opt label=disable --device /dev/fuse -ti quay.io/podman/stable
# running commands in container
cat /proc/mounts > /home/podman/before
podman run -d docker.io/busybox sleep 100
cat /proc/mounts > /home/podman/during
diff /home/podman/before /home/podman/during
# (no difference)

Parece que omitir /dev/fusetambém funciona (testado com sobreposição nativa):

podman run --user podman --security-opt label=disable -ti quay.io/podman/stable podman run -ti docker.io/busybox echo hello

Ligações

Apenas adicionando bindfsà imagem

FROM quay.io/podman/stable

RUN dnf -y install bindfs

E executando um contêiner

podman run --user podman --security-opt label=disable --device /dev/fuse -ti built_image_from_above:latest
# inside the container
cd ~ && mkdir test1 test2
bindfs --no-allow-other test1 test2
fusermount: mount failed: Operation not permitted

Estou assumindo que o comportamento será o mesmo para outras montagens de fusíveis, como sshfs. Isso pode ser um problema de permissão dentro do contêiner ou o host está negando?

Ideias

precisa de privilégio

Essa resposta implica que para usar o fuse, você precisa ter privilégios.

Setuid é mencionado, mas não tenho certeza de como isso é significado. Dentro do continer:

ls -l $(which fusermount3)
-rwsr-xr-x. 1 root root 40800 Jul 17 00:00 /usr/bin/fusermount3

sobreposição sem raiz

Também tentei remover a linha mount_programde storage.confe executar podman system reset, como descrito aqui . Mas não tenho certeza se isso é apenas sobre overlay ou também fuse. Se eu não adicionar /dev/fuse, o dispositivo não estará presente no continer:

Outra desvantagem do fuse-overlayfs é que ele requer acesso a /dev/fuse. Quando as pessoas tentam executar o Podman e o Buildah em um contêiner confinado, retiramos os privilégios CAP_SYS_ADMIN, mesmo quando executados como root. Isso nos força a usar um namespace de usuário para que possamos montar volumes. Para fazer isso funcionar, os usuários precisam adicionar /dev/fuse ao contêiner. Assim que tivermos overlay nativo para o modo sem root (sem CAP_SYS_ADMIN), /dev/fuse não será mais necessário.

Versões

Host: Fedora 41
Podman: 5.3.1

Estou tentando instalar o imagemagick para perlbrew, pois um aplicativo precisava de uma versão mais alta do perl do que a que veio com meu ubuntu, e esse aplicativo também precisa usar o imagemagick.
Estou no ubuntu jammy e estou usando o perl 5.36.3 de texto enfatizado com perlbrew.
Quando tento instalar o imagemagick com perlbrew, recebo este erro:

cpan[1]> install Image::Magick
Reading '/home/me/.cpan/Metadata'
  Database was generated on Thu, 09 Jan 2025 03:17:02 GMT
Running install for module 'Image::Magick'
Checksum for /home/me/.cpan/sources/authors/id/J/JC/JCRISTY/Image-Magick-7.1.1-28.tar.gz ok
Scanning cache /home/me/.cpan/build for sizes
............................................................................DONE
'YAML' not installed, will not store persistent state
Configuring J/JC/JCRISTY/Image-Magick-7.1.1-28.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Warning (mostly harmless): No library found for -lMagickCore-7.Q16HDRI
Generating a Unix-style Makefile
Writing Makefile for Image::Magick
Writing MYMETA.yml and MYMETA.json
  JCRISTY/Image-Magick-7.1.1-28.tar.gz
  /home/me/perl5/perlbrew/perls/perl-5.36.3/bin/perl Makefile.PL -- OK
Running make for J/JC/JCRISTY/Image-Magick-7.1.1-28.tar.gz
cp Magick.pm blib/lib/Image/Magick.pm
AutoSplitting blib/lib/Image/Magick.pm (blib/lib/auto/Image/Magick)
Running Mkbootstrap for Magick ()
chmod 644 "Magick.bs"
"/home/me/perl5/perlbrew/perls/perl-5.36.3/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Magick.bs blib/arch/auto/Image/Magick/Magick.bs 644
"/home/me/perl5/perlbrew/perls/perl-5.36.3/bin/perl" "/home/me/perl5/perlbrew/perls/perl-5.36.3/lib/5.36.3/ExtUtils/xsubpp"  -typemap '/home/me/perl5/perlbrew/perls/perl-5.36.3/lib/5.36.3/ExtUtils/typemap' -typemap '/home/me/.cpan/build/Image-Magick-7.1.1-3/typemap'  Magick.xs > Magick.xsc
mv Magick.xsc Magick.c
cc -c  -I/usr/local/include/ImageMagick-7 -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/libxml2 -I"/usr/include/ImageMagick-7" -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/freetype2 -g -O2 -Wall -pthread -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -O2   -DVERSION=\"7.1.1\" -DXS_VERSION=\"7.1.1\" -fPIC "-I/home/me/perl5/perlbrew/perls/perl-5.36.3/lib/5.36.3/x86_64-linux/CORE"  -D_LARGE_FILES=1 -DHAVE_CONFIG_H Magick.c
Magick.xs:56:10: fatal error: MagickCore/MagickCore.h: No such file or directory
   56 | #include <MagickCore/MagickCore.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:351: Magick.o] Error 1
  JCRISTY/Image-Magick-7.1.1-28.tar.gz
  /usr/bin/make -- NOT OK
Failed during this command:
 JCRISTY/Image-Magick-7.1.1-28.tar.gz         : make NO

Eu tenho o seguinte script simples que alterou a propriedade das pastas

more hola_config.sh

#!/bin/bash

chown -R hola:pola /home/darna
chmod -R 775  /home/darna

em /etc/sudoers adicionei o seguinte (o usuário super_hola é como um superusuário)

super_hola ALL=(ALL)       NOPASSWD:ALL 

mas quando executo o script como

su super_hola
whoami
super_hola

sudo -u super_hola ./hola_config.sh

Recebo Operação não permitida do chmod do script

Exemplo:

chmod: changing permissions of ‘/home/darna/linux.cvg: Operation not permitted

a questão é

por que o superusuário super_holanão pode alterar a permissão como usuário root e o que consertar na minha configuração para habilitar o usuário – super_hola para fazer isso

aqui os IDs de usuário e grupo

id super_hola
uid=1001(super_hola) gid=1001(pola) groups=1001(pola),982(docker)

grep super_hola /etc/group
docker:x:982:super_hola

id -G super_hola
1001 982

Ubuntu 22.04

Estou experimentando com IPv6pilha de protocolos no Linux e tentei descobrir quais protocolos são suportados como protocolos de camada L3 em cima de IPv6. De acordo com IANAeu executei o seguinte código simples para verificar a resposta de cada número de protocolo definido:

for i in range(1, 148):
    send(IPv6(src="::1", dst="::1", nh = i))
    sleep(1) 

No sudo tcpdump ip6 -n -vvv -i loI vejo que a maioria dos protocolos não são suportados, ou seja:

00:31:12.081361 IP6 (hlim 64, next-header unknown (37) payload length: 0)
   ::1 > ::1:  ip-proto-37 0
00:31:12.081371 IP6 (flowlabel 0x11111, hlim 64, next-header ICMPv6 (58) payload length: 48)
   ::1 > ::1: [icmp6 sum ok] ICMP6, parameter problem, next header - octet 6

Isso significa que a IPv6implementação da pilha de protocolos do Linux não entende o número do protocolo (nesse caso, era 37).

Os únicos números suportados além dos números de cabeçalhos de extensão eram:

TCP,     next header = 6
UDP,     next header = 17
ICMPv6,  next header = 58
PIM,     next header = 103
UDPLite, next header = 136

Note que even IPv6, next header = 41não foi reconhecido. Isso significa que IPv6a implementação do Linux não está em conformidade no sentido de RFC 8200?

Meu objetivo é dar um laptop (com Debian) para uma pessoa que só vai usá-lo para navegar na web. E que não vai abrir o terminal para digitar sudo apt update...etc.

Comecei a procurar e me disseram que o gnome-software update resolve o problema.

Mas então aqui está minha pergunta: como é feito o reboot? Imagino que seja frequentemente necessário.

A necessidade de reinicialização é explicitamente sinalizada ao usuário?

Preciso executar vários scripts de shell sequencialmente (s1.sh, s2.sh, s3.sh) com o seguinte requisito:

• Se um script não produzir nenhuma saída (stdout ou stderr) por 1 minuto, ele deve ser encerrado
• Após o término, o próximo script na sequência deve ser executado automaticamente
• Isso deve continuar até que todos os scripts sejam processados

Situação atual:

• Os scripts não saem sozinhos quando sua tarefa é concluída
• Atualmente, monitoro manualmente cada script e pressiono Ctrl-cquando não percebo nenhuma saída por um tempo
• É preciso automatizar esta intervenção manual

Exemplo de fluxo de trabalho:

1. Execute s1.sh
2. Se s1.sh ficar em silêncio por 1 minuto → encerre-o → execute s2.sh
3. Se s2.sh ficar em silêncio por 1 minuto → encerre-o → execute s3.sh
4. ...e assim por diante

Abordagem potencial que estou considerando: Estou pensando em redirecionar stdout e stderr para um arquivo e verificar o tempo de modificação do arquivo a cada segundo. Se o arquivo não tiver sido gravado por 1 minuto, eu poderia assumir que o script não tem saída e matá-lo. No entanto, não tenho certeza se essa abordagem é viável ou se há soluções melhores.

Alguém implementou algo parecido? Obrigado.

Tenho usado o iptables-savecomando recentemente (combinado com iptables-restore) e notei um comportamento inconsistente que não entendo. Tenho certeza de que não é um bug, pois é um comando muito popular para ter passado despercebido, o que significa que é meu próprio entendimento que está falho. Dei uma olhada nas páginas de manual e em várias fontes de documentação, mas não consegui encontrar nada que explicasse o que observei.

O problema é que quando executo o comando iptables-save, espero ver a filtertabela despejada no stdout (conforme a documentação). O que vejo de fato é absolutamente nada, por exemplo:

[root@rhel9 ~]# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[root@rhel9 ~]# 
...
[root@rhel9 ~]# iptables-save
[root@rhel9 ~]# 

Como você pode ver, não há saída para nada stdoutdo comando. Da mesma forma, se eu executar o comando e tentar redirecionar a saída ou passar a -f <output file>opção, a saída ainda estará em branco.

Se eu especificar a tabela que desejo visualizar, obtenho uma saída, por exemplo:

[root@rhel9 ~]# iptables-save -t filter
# Generated by iptables-save v1.8.8 (nf_tables) on Wed Jan  8 16:43:11 2025
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Wed Jan  8 16:43:11 2025

Se eu salvar essa saída em um arquivo, digamos ipv4backup, e então chamar iptables-restoreesse arquivo, o comportamento iptables-saveserá diferente:

[root@rhel9 ~]# iptables-restore ipv4backup
[root@rhel9 ~]# 
[root@rhel9 ~]# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[root@rhel9 ~]# 
[root@rhel9 ~]# iptables-save
# Generated by iptables-save v1.8.8 (nf_tables) on Wed Jan  8 16:44:03 2025
*filter
:INPUT ACCEPT [5:305]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5:914]
COMMIT
# Completed on Wed Jan  8 16:44:03 2025

As tabelas contêm o mesmo conteúdo do exemplo acima, mas há um comportamento diferente dependendo iptables-savese iptables-restorefoi chamado anteriormente.

Testei isso no RHEL9 e no Ubuntu 22.04 e ambos apresentam o mesmo comportamento. No SuSE 15, o comando foi executado e produziu saída de todas as tabelas, independentemente de iptables-restoreterem sido executadas anteriormente. Os ip6tables...comandos equivalentes apresentam o mesmo comportamento.

Então, a questão é (com base no comportamento observado acima): por que iptables-savenão produz saída quando as tabelas estão vazias, mas se restaurarmos tabelas vazias e chamarmos o comando novamente, obtemos a saída esperada (que são tabelas vazias)?

Contexto: Servidor Ubuntu 24.04 de 64 bits no Raspberry pi 3B+

sudo systemctl status ssh

Resultados após reiniciar o servidor ssh. Por que a segunda linha indica desabilitado? Como diagnosticar/testar? Que limitação isso impõe?

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; disabled; preset: enabled)
     Active: active (running) since Wed 2025-01-08 07:35:43 UTC; 8h ago
TriggeredBy: ● ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 1584 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 1586 (sshd)
      Tasks: 1 (limit: 853)
     Memory: 1.1M (peak: 2.9M)
        CPU: 303ms
     CGroup: /system.slice/ssh.service
             └─1586 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Jan 08 07:35:43 rpi3mqtt systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Jan 08 07:35:43 rpi3mqtt sshd[1586]: Server listening on :: port 22.
Jan 08 07:35:43 rpi3mqtt systemd[1]: Started ssh.service - OpenBSD Secure Shell server.
Jan 08 14:48:16 rpi3mqtt sshd[2411]: Connection closed by authenticating user ubuntu 192.168.8.242 port 64789 [preauth]

Conforme solicitado nos comentários:

sudo systemctl status ssh.socket

● ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/usr/lib/systemd/system/ssh.socket; enabled; preset: enabled)
     Active: active (running) since Wed 2025-01-08 19:03:57 UTC; 2h 36min ago
   Triggers: ● ssh.service
     Listen: [::]:22 (Stream)
      Tasks: 0 (limit: 853)
     Memory: 8.0K (peak: 256.0K)
        CPU: 3ms
     CGroup: /system.slice/ssh.socket

Jan 08 19:03:57 rpi3mqtt systemd[1]: Listening on ssh.socket - OpenBSD Secure Shell server socket.

Tenho um script bash que abre uma janela com notify-send. Gostaria de fechar essa janela quando o script terminar, mas não consigo encontrar nada para kill.

A pergunta é uma duplicata de https://askubuntu.com/questions/639754/is-it-possible-to-cancel-or-clear-a-notification-created-by-using-notify-send , mas nenhuma das respostas funciona para mim. A resposta aceita diz para matar um processo chamado notify-osd, mas não tenho nada parecido. É perceptível que essa pergunta tem dez anos.

Meu roteiro é como

notify-send -u critical -i ~/.icons/my-icon.png "$titletext" "$helptext"
helppid=$!
…
kill $helppid

(A configuração de urgência é crítica para que a janela Ajuda permaneça aberta até ser explicitamente descartada.)

O problema é que $!não retorna um valor. ps -ef | grep -i notifyNão mostra nada conectado ao meu script.

Encontrei uma solução alternativa usando o print-idrecurso notify-send(descrito em https://askubuntu.com/a/161852 ):

print-id=$(notify-send -p -u critical -i ~/.icons/my-icon.png "$titletext" "$helptext")
notify-send -r $print-id -u low ~/.icons/my-icon.png "$titletext" Finished

Alguém pode descrever uma maneira melhor de dispensar o diálogo de ajuda? Li recomendações para yad, e estou pensando se devo instalar e avaliar.

Se eu fizer isso: ls 1>/dev/nullentão, como esperado, não há saída para a tela porque ela foi redirecionada para /dev/null. No entanto, se eu fizer isso, ls 1>/dev/null | lessvejo a listagem de arquivos do diretório atual. Como?!?