O Ubuntu Linux com systemd + nenhum login de usuário + aplicativos sob medida funcionam sem shells?

Question

Isso é " O linux pode funcionar sem um shell? ", mas focando puramente na mecânica de remoção de shells sem o distrações nessa outra questão.

Considere o mesmo sistema que existe: Ubuntu Linux Server LTS versão 16 com sistemas sob medida compreendendo binários compilados rodando como serviços systemd, sem nenhum usuário final (ou mesmo administrador) de login.

Como remover os reservatórios? Quais seriam os resultados de fazer isso? De remover o shell Bourne Again? De remover /bin/sh ? Até que ponto esse sistema ainda pode ser executado?

Note que esta questão não está relacionada com porque alguém pode querer fazer isso, com terminais, como proteger um sistema, ou com comandos que podem ser executados a partir de conchas. O foco aqui é em conchas, o mecanismo de remoção e as conseqüências.

    

Answer 1

Isso é bastante complexo de se considerar. Para começar:

• O padrão POSIX a.k.a. the Single Unix Specification, fornece uma garantia de que um sistema em conformidade terá um programa invokable como sh que implementa uma Linguagem Shell específica. Em qualquer sistema real, sh será realmente uma das conchas reais, como a casca Z, a casca de Almquist, a casca de Korn, a casca de Bourne Again, e assim por diante; geralmente reconhecendo que ele foi invocado pelo nome sh e operando em um modo POSIX .
• Mais de uma década atrás, as comunidades Debian e Ubuntu trabalharam duro para eliminar as dependências de várias partes do sistema operacional em extensões fornecidas pelo shell Bourne Again, mesmo em seu modo POSIX. Scripts que especificaram #!/bin/sh como seu intérprete foram obrigados a não confiar nos chamados Bashisms e, inversamente, os scripts que dependiam do Bashisms tiveram que declarar explicitamente o shell Bourne Again como seu interpretador e não sh .
• As pessoas do sistema definiram como um de seus objetivos em 2011 a eliminação do uso de scripts de shell como parte do gerenciamento de sistemas e serviços.

Como um remove os shells é fácil, mais ou menos. Um remove pacotes como ash , bash , posh , mksh , pdksh , tcsh , dash e assim por diante; usando uma ferramenta de gerenciamento de pacotes, como aptitude . A parte difícil é que dois deles são marcados como "essenciais" - dash e bash -, o que significa que outros pacotes podem assumir sua presença sem declarar explicitamente uma dependência deles, e não é trivial removê-los como o gerenciador de pacotes irá, intencionalmente, exigir que você pule em aros extras para confirmar que você realmente deseja removê-los.

O problema vem com as conseqüências de fazer isso.

• Graças ao trabalho do pessoal do Debian e do Ubuntu, agora existem scripts que explicitamente declaram #!/bin/bash como seu interpretador de scripts. Tais scripts falharão em funcionar se o shell Bourne Again for removido, mesmo se alguém mantiver o shell do Debian Almquist.
• Scripts que dependem de um shell em conformidade com POSIX deixarão de funcionar se o shell do Debian Almquist for removido.
• Programas compilados que dependem de um shell em conformidade com POSIX não funcionarão se o shell do Debian Almquist for removido. Esses programas fazem coisas como chamar a função system() library ou explicitamente execvpe() the sh utility.

Como resultado:

• Os programas aplicativos podem não funcionar. Sim, eles são escritos em uma linguagem compilada e não são scripts de shell. Isso não impede que os programadores de aplicativos rapidamente bifurcem e executem o processo de shell ímpar aqui e ali.
• Os programas do sistema podem não funcionar. Pelo mesmo motivo.
• Os programas do sistema podem não funcionar porque são realmente scripts de shell.
  • A eliminação de scripts de shell dos processos de inicialização e encerramento não é total, por um longo giz. Muitos serviços ainda são controlados por van Smoorenburg rc scripts, que falharão se não houver sh para interpretá-los. Executar

    systemctl list-units

    Todos os serviços que você vê com "LSB:" ou "SYSV:" no início de suas descrições precisam de um interpretador de shell para funcionar. Da mesma forma, programas como rabbitmq-server ou mysqld_safe , que às vezes são (ab) usados como serviços, são, na verdade, scripts de shell.
  • Muitos programas auxiliares e utilitários são scripts de shell. O /lib/systemd/systemd-sysv-install do Debian é apenas para um exemplo. Outros incluem /usr/sbin/service , /usr/sbin/invoke-rc.d e até /bin/fgrep .
• O bootstrap do modo de recuperação e de emergência não funcionará. Tanto rescue.service como emergency.service (a partir da versão do systemd que está no Ubuntu 16) usam /bin/sh .

Leitura adicional

• traço como /bin/sh . Wiki do Ubuntu.
• traço como /bin/sh . Wiki do Debian.
• bashisms . O wiki do Greg.
• Existe alguma razão para ter uma shebang apontando para / bin / sh em vez de / bin / bash?
• Lennart Poettering (2011-04-20). systemd para administradores, parte VIII . 0pointer.de.
• link