All perguntas(unix)

Não sou um usuário forte de Linux, mas quero entender melhor o material neste post aqui que fala sobre namespaces Linux

https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory

Acho que minha incapacidade de compreensão pode estar relacionada à compreensão insuficiente de "comando", "processo" e talvez algumas outras coisas.

Primeiro, deixe-me explicar um experimento simples que estou usando para minha educação. Abri duas janelas de terminal PUTTY. Em cada janela, fiz um ssh root@[ip of machine]. Agora que tenho 2 sessões SSH para minha máquina Linux, começo meus experimentos.

Na primeira janela, fiz isso:

root@localhost:~# unshare --pid /bin/bash
bash: fork: Cannot allocate memory

Na segunda janela, fiz isso:

root@localhost:~# ps -aux | grep unshare
root       58188  0.0  0.0   6480  2284 pts/3    R+   21:49   0:00 grep --color=auto unshare

Aqui estão minhas perguntas:

1. A segunda janela não mostra nenhuma indicação de unshare --pid /bin/bash. Isso ocorre porque o /bin/bashcomando ou o /bin/bashprocesso já havia terminado? É por isso que muitos usuários de Linux na internet recomendam usar o --forkpara que o /bin/bashseja executado no namespace recém-criado?

2. A resposta aceita declarou isto: "Depois que o bash começar a rodar, o bash irá bifurcar vários novos subprocessos para fazer algumas coisas." Não entendi o significado desta frase. Então, na segunda janela do terminal, eu rodei isto:

root@localhost:~# unshare -pf /bin/bash
root@localhost:~# ps -a
    PID TTY          TIME CMD
  58278 pts/2    00:00:00 sudo
  58279 pts/2    00:00:00 su
  58280 pts/2    00:00:00 bash
  58291 pts/2    00:00:00 unshare
  58292 pts/2    00:00:00 bash
  58299 pts/2    00:00:00 ps

PID 58278 a PID58299 é o que o autor quis dizer com "o bash bifurcará vários novos subprocessos para fazer algumas coisas"?

Estou percebendo um comportamento estranho para nsentero qual estou procurando uma explicação.

Quando entro nos namespaces de outro processo criado, unshareobservo as diferenças no comportamento resultante entre os casos em que especifico o diretório raiz como um caminho regular e em que uso /proc/PID/rootum link simbólico.

Aqui está o exemplo de configuração.

1. Preparar processo de destino

   sudo unshare --mount --mount-proc --pid --fork --root /tmp/jail bash
   

   /tmp/jailtem um distributivo linux dentro (eu o preparo docker exportusando ubuntuimagem):

   $ docker run ubuntu
    (grab the container ID)
   $ docker export 8c67e1fb5443 > ubuntu.tar
   $ mkdir /tmp/jail && cd /tmp/jail && tar -xf ~/ubuntu.tar
   

2. De outro terminal tente inserir os namespaces desse processo

   sudo nsenter --target=28716 --root=/tmp/jail --all bash
   

3. psComando Try

   Aqui observo o erro:

   root@ubuntu:/proc# ps
   Error, do this: mount -t proc proc /proc
   
   root@ubuntu:/proc# mount
   mount: failed to read mtab: No such file or directory
   

No entanto, se eu especificar --root=/proc/28716/root, nsenterde repente ele começa a funcionar.

$ sudo readlink /proc/28716/root
/tmp/jail

$ sudo nsenter --target=28716 --root=/proc/28716/root --all bash

root@ubuntu:.# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   4624  3712 ?        S+   21:04   0:00 bash
root          31  0.0  0.0   4624  3712 ?        S    21:10   0:00 bash
root          39  0.0  0.0   7060  2944 ?        R+   21:10   0:00 ps aux

root@ubuntu:.# mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

Quais são as razões para esse comportamento? Por que symlink vs. regular path faz diferença, já que eles apontam para o mesmo diretório?

$ sudo nsenter --target=28716 --root=/proc/28716/root --all bash  # WORKS GOOD
$ sudo nsenter --target=28716 --root=/tmp/jail --all bash         # DOES NOT WORK GOOD

 (where /proc/28716/root is symlink to /tmp/jail)

Nem straceo código fonte nem o código fonte nsenterparecem sugerir a explicação para essas diferenças.

6.8.0-49-generic
Ubuntu 24.04.1 LTS

É possível executar um comando de histórico por número com !###, similar ao bash/zsh? O shell ash do Alpine não interpreta isso:

$ history
1441 date
1442 history

$ !1141
-sh: !1141: not found

Ao executar sudo apt-get upgraderecebo o seguinte erro:

/bin/sh: 1: /usr/bin/apt-listchanges: not found
E: Sub-process /usr/bin/apt-listchanges --apt || test $? -lt 10 returned an error code (1)
E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10

A mesma coisa ocorre ao usar o aplicativo Discover para atualizar pacotes. A maioria dos aplicativos pode ser atualizada, mas o software do sistema não. Isso é particularmente problemático, pois as atualizações de segurança não podem ser instaladas/baixadas.

O que estou executando:

OS: Debian GNU/Linux 12 (bookworm) x86_64 
Host: Intel Z690
Kernel: 6.1.0-26-amd64
Packages: 2520 (dpkg), 35 (flatpak), 8 (snap)
Shell: bash 5.2.15
DE: Plasma 5.27.5
CPU: 12th Gen Intel i3-12100F (8) @ 5.500GHz
GPU: NVIDIA GeForce RTX 3060 Lite Hash Rate

Usando a versão GNU de todas as 3 ferramentas (role para baixo para ver as tentativas do FreeBSD), se eu quisesse encontrar 'na entrada usando o awk com um 'script delimitado por -, poderíamos tentar corresponder usando as sequências de escape hexadecimais e octais:

$ echo "'" | awk '/\x27/'
'

$ echo "'" | awk '/\047/'
'

$ echo "'" | awk '/\o047/'
awk: cmd. line:1: warning: regexp escape sequence `\o' is not a known regexp operator

então os 2 primeiros funcionam e o 3º não, como você esperaria intuitivamente.

Agora vamos tentar o mesmo com sed (com ou sem -E):

$ echo "'" | sed -n '/\x27/p'
'

$ echo "'" | sed -n '/\047/p'
$

$ echo "'" | sed -n '/\o047/p'
'

e grep (também com ou sem -E):

$ echo "'" | grep '\x27'
grep: warning: stray \ before x

$ echo "'" | grep '\047'
grep: warning: stray \ before 0

$ echo "'" | grep '\o047'
grep: warning: stray \ before o

Então:

1. Mais importante: por que eles são diferentes?
2. Curiosidade secundária: Existe uma maneira de usar uma sequência de escape no grep para corresponder 'sem recorrer à opção não portátil do GNU grep -Pe sem expandir a sequência de escape antes que o grep a veja usando construções de shell como grep $'\047'?

Vale ressaltar que octal \047é a sequência de escape recomendada no awk (veja http://awk.freeshell.org/PrintASingleQuote ou https://web.archive.org/web/20230530010453/http://awk.freeshell.org/PrintASingleQuote se estiver inativo).

Para os propósitos desta questão, não estou interessado em alternativas que permitam literal 'ou o que qualquer outra ferramenta faz ou qualquer outra coisa, estou apenas tentando descobrir por que essas 3 ferramentas específicas de correspondência de regexp tratam sequências de escape ASCII de forma diferente umas das outras. Eu estaria, no entanto, interessado em aprender como o BSD ou outras variantes dessas 3 ferramentas se comportam, dados os mesmos scripts mostrados acima.

Informações adicionais:

FreeBSD

Este é o comportamento do FreeBSD 13.1:

% echo "'" | awk '/\x27/'
'
% echo "'" | awk '/\047/'
'
% echo "'" | sed -n '/\x27/p'
'
% echo "'" | sed -n '/\047/p'
% echo "'" | sed -n '/\o047/p'
sed: 1: "/\o047/p": RE error: trailing backslash (\)
% echo "'" | grep '\x27'
grep: trailing backslash (\)
% echo "'" | grep '\047'
% 

POSIX

Veja o que os padrões POSIX para Expressões Regulares e as 3 ferramentas em questão dizem sobre isso:

• expressões regulares: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap09.html
• awk: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/awk.html
• sed: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html
• grep: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/grep.html

Da especificação regexp vemos que nem xnem 0são "Caracteres Especiais" em um BRE ou ERE , portanto são "Caracteres Ordinários" e que

Quando não está dentro de uma expressão entre colchetes, a interpretação de um caractere comum precedido por um caractere sem escape é indefinida, exceto para:

seguido por listas de caracteres, nenhum dos quais inclui 0ou xpara BREs ou EREs, então minha conclusão é que nem \x27nem \047são comportamentos definidos em uma expressão regular por POSIX.

A seção Expressões Regulares da especificação POSIX awk diz:

\ddd
Um caractere seguido pela sequência mais longa de um, dois ou três caracteres de dígito octal (01234567). Se todos os dígitos forem 0 (ou seja, representação do caractere NUL), o comportamento é indefinido. Se os dígitos produzirem um valor maior que o octal 377, o comportamento é indefinido.

então sabemos que \0é definido para um awk POSIX, mas \xnão é, então o comportamento do awk \xnão é definido pelo POSIX para o awk e, portanto, é deixado para as várias implementações do awk.

A seção Expressões regulares da especificação POSIX sed adiciona algumas alterações ao regexp, mas não menciona \0or \xe remete às definições de regexp POSIX e, portanto, \0or \xnão são definidos pelo POSIX para sed.

A seção Descrição da especificação grep do POSIX se refere inteiramente às definições de expressões regulares do POSIX e, portanto \0, \xnão são definidas pelo POSIX para grep.

Então, aparentemente, o significado de \xddé deixado para os implementadores de ferramentas para grep, sed e awk, enquanto o significado de \0ddé definido para awk, mas deixado para os implementadores de grep e sed.

Manuais GNU

A seção Sequências de escape do manual do GNU awk diz:

\nnn
O valor octal nnn, onde nnn representa de 1 a 3 dígitos entre '0' e '7'. Por exemplo, o código para o caractere ASCII ESC (escape) é '\033'.

\xhh…
O valor hexadecimal hh, onde hh representa uma sequência de dígitos hexadecimais ('0'–'9', e 'A'–'F' ou 'a'–'f'). São permitidos no máximo dois dígitos após '\x'...

então é aí que \x47o GNU awk é definido.

A seção Sequências de Escape do manual do GNU sed diz:

\oxxx
Produz ou corresponde a um caractere cujo valor ASCII octal é xxx.

\xxx
Produz ou corresponde a um caractere cujo valor hexadecimal ASCII é xx.

então é onde \o047e \x27são definidos para o GNU sed.

O manual do GNU grep não contém nenhuma referência que eu tenha encontrado sobre sequências de escape hexadecimais ou octais, o que explica as mensagens de aviso que vemos quando tentamos usá-las e provavelmente significa que elas simplesmente não são suportadas no GNU grep.

Quando me conecto a um macOS Sonoma remoto a partir de um Linux RHEL 8 ssh -J user@portal user@mace, uma vez conectado, executo o vim somefile, recebo alguns caracteres estranhos no canto superior esquerdo da "página" e também no prompt do shell após sair do Vim:

[>4;m

^{nota: não consegui capturar esses bytes corretamente, não sei como posso fazer isso}

Não é a primeira vez que enfrento esse problema com diferentes combinações de sistemas operacionais locais/remotos (Solaris/FreeBSD/AIX/Linux/macOS), mas antes eu só precisava instalar os terminfopacotes nos NIXs remotos para consertar.

No macOS Sonoma, o terminfo xterm-256colorusado pelo RHEL 8 já está em /usr/share/terminfo/78/xterm-256color, e mudar TERMpara xtermnão ajuda.

Alguma ideia do que fazer para resolver o problema?

Tenho bind9 em execução para DNS LAN local. Também tenho um servidor de cache APT. Então, configurei um arquivo RPZ para envenenar certos nomes de domínio e fazer com que eles sejam resolvidos para meu servidor de cache interno. A execução de eg apt updateestá retornando erros de resolução , acho que porque o servidor de cache não consegue resolver os registros verdadeiros (externos) e buscar os dados. Acho que isso significa que eu teria que configurar uma visualização para o servidor de cache como /32.

Então a questão é, posso configurar para que meu servidor de cache que atinge domínios na zona envenenada seja apenas encaminhado, enquanto o resto da rede recebe os dados envenenados? Só não tenho certeza de como fazer isso.

Nunca usei o ZFS para nada (que eu saiba).

Para minha surpresa, há 4 pacotes instalados por padrão na minha nova instalação do Linux Mint 22 (Cinnamon).

Naturalmente, minha pergunta é: se eu posso desinstalar todos os pacotes relacionados ao ZFS se usar ext4 para tudo? Com ​​segurança, quero dizer, se ele não for usado internamente de forma alguma. E se eu puder, como exatamente devo proceder?

Desde que troquei do Ubuntu para o Manjaro há vários meses, tenho tido um problema estranho: não consigo logar no console virtual, sempre recebo uma mensagem de "Login incorreto", embora todas as outras autenticações tenham funcionado perfeitamente. Hoje, finalmente decidi resolver isso, mas não tive sucesso.

gettyparece funcionar normalmente e invocar loginconforme o esperado.

$ ps auxww |grep getty
root      129384  0.0  0.0   7176  3880 tty3     Ss+  22:47   0:00 /sbin/agetty -o -p -- \u --noclear - linux

Verifiquei que não há sobras /etc/nologinde ou /var/run/nologin, e as configurações relacionadas ( /etc/login.defs, /etc/security/*) estão totalmente intocadas e são padrões de distribuição bastante permissivos.

No entanto, ao tentar efetuar login no VC, estou recebendo (depois de habilitar a debugopção para alguns módulos PAM):

dic 06 22:46:53 s0me0ne login[128494]: pam_systemd_home(login:auth): pam-systemd-homed authenticating
dic 06 22:46:53 s0me0ne login[128494]: pam_systemd_home(login:auth): New sd-bus connection (system-bus-pam-systemd-home-128494) opened.
dic 06 22:46:53 s0me0ne login[128494]: pam_systemd_home(login:auth): systemd-homed is not available: Could not activate remote peer 'org.freedesktop.home1': activation request failed: unknown unit
dic 06 22:46:53 s0me0ne login[128494]: pam_unix(login:auth): username [s0me0ne] obtained
dic 06 22:46:55 s0me0ne unix_chkpwd[129255]: password check failed for user (s0me0ne)
dic 06 22:46:55 s0me0ne login[128494]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty3 ruser= rhost=  user=s0me0ne
dic 06 22:46:56 s0me0ne login[128494]: FAILED LOGIN 1 FROM tty3 FOR s0me0ne, Authentication failure

Verifiquei novamente se todas as unix_chkpwdinstâncias presentes no sistema são SUID root e são hardlinks para o mesmo binário:

$ ls -li /usr/bin/unix_chkpwd /sbin/unix_chkpwd                                                                                                                                               
220202420 -rwsr-sr-x 1 root root 26672 18 nov 12.58 /sbin/unix_chkpwd
220202420 -rwsr-sr-x 1 root root 26672 18 nov 12.58 /usr/bin/unix_chkpwd

Então me lembrei do bom e velho pamtestertruque e tentei:

$ pamtester -v login s0me0ne authenticate                                                                                                                                                                                                                                                                 pamtester: invoking pam_start(login, s0me0ne, ...)
pamtester: performing operation - authenticate
Password: 
pamtester: successfully authenticated

Funcionou perfeitamente e o PAM está feliz, sem erros nos logs.

A última coisa que tentei foi testar manualmente a unix_chkpwdfuncionalidade:

$ mkfifo /tmp/pw
$ echo -ne 'mypassword\0' >/tmp/pw &
[1] 137112
$ /sbin/unix_chkpwd s0me0ne nullok </tmp/pw
[1]  + done       echo -ne 'mypassword\0' > /tmp/pw
$ echo $?
0

Neste ponto, estou completamente travado e coçando a cabeça. Qualquer ideia é bem-vinda.

Esta questão está intimamente relacionada a: Como inserir texto antes da primeira linha de um arquivo? . Eu deliberadamente fiz o título parecido com o daquela questão para destacar isso.

Exceto que o arquivo de destino é UTF-8 com BOM.

Então, eu quero adicionar uma primeira linha a um arquivo que tem bytes UTF-8 BOM em seu cabeçalho ( 0xef 0xbb 0xbfcaracteres). Pelo menos os arquivos UTF-8 com BOM que eu tenho aqui começam com isso.

Se eu simplesmente seguir em frente e seguir as soluções na questão relacionada,

sed "1i My First line is now this." file.txt

Eu obterei (no VSCode no meu caso) algo como

My First line is now this.
?The first line was this one
Second line and so on

Estando ?na segunda linha o caractere UTF-8 para expressar algo não imprimível.

Outra consequência, como seria de se esperar, é que o arquivo não abre mais como UTF-8 com BOM e agora dependemos dos recursos do editor de texto para "adivinhar" sua codificação. Determinamos um padrão em nosso projeto para ter arquivos com BOM para garantir que tudo esteja na mesma codificação.

Como preservo o cabeçalho da lista de materiais no arquivo ao adicionar o texto?