Como o SO sabe que um comando precisa de sudo?

Question

1. Quando você executa um executável, às vezes o sistema operacional nega permissão para. Por exemplo, executando make install com o prefixo ser um caminho do sistema precisará de sudo , enquanto o prefixo é um o caminho que não seja do sistema não será solicitado para sudo . Como o sistema operacional decide que executar um executável exigiria mais privilégios do que um usuário tem, mesmo antes do programa fazer alguma coisa?
2. Às vezes, a execução de um programa não terá permissão negada, mas o O programa poderá fazer mais coisas se for executado com sudo . Para Por exemplo, ao executar du em algum diretório do sistema, somente com sudo poderá acessar algum diretório. Por que o sistema operacional não negar permissão de executar tal programa, ou amigável notificar mais privilégio é preferível, antes que o programa possa ser executado?
3. É verdade que sempre que sudo funcionar, su também funcionará e sempre que su funcionar, sudo também funcionará? ou com su , um usuário pode fazer mais do que com sudo ? Como o SO decide quando sudo funciona e quando su é necessário?

Answer 1

1. Às vezes, a mensagem "Permissão negada" é devido a permissões do sistema de arquivos que negam o acesso de gravação, por exemplo. O executável / ferramenta simplesmente verifica se o sistema de arquivos lhe concede permissões suficientes para fazer o que você está prestes a fazer e lança um erro se for negado pelo sistema de arquivos. Outras vezes, a própria ferramenta verificará seu ID de usuário antes de permitir que você continue a usá-lo.
2. Quando você executa um programa com sudo , ele está sendo executado com o nome de outro usuário. Se esse usuário for "capaz de fazer mais coisas" do que seu usuário e a configuração sudo permitir que você faça isso em nome do outro usuário, então sim, sudo permitirá que você faça mais coisas. Isso não é necessário, no entanto. Se você apenas coloca sudo no início da linha de comando, você está realmente sudo ing como root , então tipicamente você é capaz de fazer mais coisas do que um mero mortal.
3. Definitivamente não. Para usar sudo , você precisa fornecer sua própria senha de usuário e, em seguida, pode fazer algumas coisas em nome do usuário de destino. Para usar su , você precisa da senha do usuário alvo e, se tiver, você se torna o usuário alvo no que diz respeito ao sistema e pode fazer qualquer coisa que o usuário possa fazer.

Veja também

• Por que a senha 'sudo' é diferente da senha 'su root'

Answer 2

Para os propósitos que você descreveu, o sistema operacional não decide se você precisa do sudo para inicialmente executar o programa. Em vez disso, depois que o programa começa a ser executado e, em seguida, tenta fazer algo que não é permitido pelo usuário atual (como gravar um arquivo em /usr/bin para instalar um novo comando), o sistema operacional impede o acesso ao arquivo. A ação para assumir essa condição depende do programa; make pára de ser executado, mas du prosseguirá para o próximo arquivo / diretório após imprimir uma mensagem.

Os comandos su e sudo são duas maneiras diferentes de executar um programa com privilégios de root. Eles podem diferir em detalhes menores, como o conteúdo do ambiente ao iniciar o novo programa, dependendo das opções usadas. O sistema operacional não precisa decidir quando um ou outro pode funcionar.

    

Answer 3

su e sudo são programas privilegiados. su altera (após a autenticação bem-sucedida) o usuário real e o efetivo e o id do grupo para o usuário que você é su . Portanto, su é semelhante a login . Note que su pode ser usado para mudar para qualquer usuário, não apenas para root. sudo também altera os IDs de usuário e grupo reais e efetivos. Até este ponto su e sudo são semelhantes (mas não relacionados), além disso são muito diferentes.

Com su , você precisa saber a senha do alvo e, depois de autenticado, pode fazer o que quiser com esse usuário. O uso de su pode ser restrito configurando SU_WHEEL_ONLY em /etc/login.defs . Se estiver definido, apenas os usuários do grupo wheel poderão usar su , caso contrário, ele não será restrito. Além disso, su é tudo ou nada.

sudo é completamente diferente em relação a isso. Com sudo , você pode definir políticas bastante complexas em /etc/sudoers sobre o que o sudoer (o usuário que chama sudo ) tem permissão para fazer. Por exemplo, você pode definir políticas em que determinados usuários podem executar apenas determinados programas com determinados privilégios, enquanto outros usuários podem executar outros programas com outros privilégios.

Um dos recursos impressionantes de sudo é que você pode configurá-lo de tal forma que um usuário tenha que se autenticar com sua própria senha (em vez da do destino). Assim, sudo se tornou muito popular entre os administradores, pois permite autorizar os usuários a fazer apenas operações privilegiadas definidas sem lidar com a senha de superusuário, além de você obter algum grau de responsabilidade.

    

Answer 4

tl; dr O acesso é determinado pelo usuário que está executando o aplicativo e sudo executa aplicativos como usuário diferente.

Versão completa:

How does the OS know that a command needs sudo?

Não sabe. O UNIX gerencia as permissões não no nível do aplicativo, mas no nível do sistema de arquivos: as permissões são concedidas para os usuários acessarem arquivos específicos. Os aplicativos, então, são executados em nome do usuário - cada processo em execução possui um usuário associado a ele. Esse usuário é usado para determinar as permissões para esse aplicativo. O Sudo funciona executando aplicativos em nome de outro usuário (com permissões associadas a outro usuário), ou seja, root , o superusuário.

Quanto aos seus exemplos:

1. Se o usuário tiver acesso de gravação a um diretório específico, ele poderá make install nesse diretório. Caso contrário, eles podem ter root fazer isso - usando sudo .

2. Se você não puder acessar arquivos em um diretório, du em execução para você não poderá acessá-lo também. root pode acessar praticamente todos os arquivos, então sudo du ( du executado em nome de root ) também pode acessá-los.

Is it true that whenever sudo works, su will also work, and whenever su works, sudo will also work?

Sim e não. Sim, se o programa for na verdade executado, ele deve se comportar da mesma maneira em sudo e su . No entanto, sudo fornece um controle mais refinado de quem pode executar o que, por conjunto de regras armazenadas no arquivo /etc/sudoers . su é mais simples - se você souber a senha do usuário-alvo, poderá executar programas em nome desse usuário.

Última nota: como o aplicativo lida com negação de acesso (onde ele aborta, ignora ou avisa o usuário) depende da aplicação.

    

Answer 5

Ninguém tem um ✓ ainda, então eu coloquei uma resposta que tem tudo que eu conseguia pensar.

1 Quando você executa um executável, às vezes o sistema operacional negará sua permissão para. Por exemplo, executar make install com o prefixo sendo um caminho do sistema precisará de sudo, enquanto que com o prefixo sendo um caminho que não seja do sistema, não será solicitado sudo. Como o sistema operacional decide que a execução de um executável exigiria mais privilégios do que um usuário, mesmo antes de o programa fazer alguma coisa?

Não, isso não é feito quando um executável é iniciado. Isso é feito quando o executável tenta fazer alguma coisa.

O sistema operacional verificará as permissões e os recursos do sistema de arquivos (eles não são cobertos pelas permissões do sistema de arquivos e incluem um bom nível, mknode, alguns itens de rede de baixo nível, processos de outros, reinicialização, horário etc. ). Se você não tem as permissões, então você não pode fazê-lo. Raiz tem um conjunto completo de recursos, incluindo CAP_DAC_OVERRIDE (ignorar permissão de arquivo).

2 Às vezes, não será negada a execução de um programa, mas o programa poderá fazer mais coisas se for executado com o sudo. Por exemplo, quando rodando du em algum diretório do sistema, somente com o sudo ele poderá acessar algum diretório. Por que o sistema operacional não nega a permissão de executar um programa desse tipo, ou é mais recomendável notificar o privilégio, antes que o programa possa ser executado?

O SO não pode saber o que o programa fará. Portanto, cabe ao programa verificar as permissões antes de começar e decidir o que fazer. Não tem que fazer isso embora.

Nota: no android há um manifesto, neste aplicativo o aplicativo declara quais privilégios ele pode usar. O sistema operacional matará qualquer aplicativo que tente usar um privilégio que ele não declare e o sistema operacional nem sempre garante que um privilégio possa ser honrado. por exemplo. o acesso à rede pode não estar disponível.

2 É verdade que sempre que o sudo funciona, o su também funciona, e sempre que o su funciona, o sudo também funciona? ou com su, um usuário pode fazer mais do que com o sudo? Como o SO decide quando o sudo funciona e quando o su é necessário?

sudo e su fazem aproximadamente o mesmo. Algumas diferenças são o manuseio de variáveis de ambiente e outras evitações de segurança. No entanto, ambas são ferramentas para permitir que você se torne outro usuário, e ambos têm um usuário padrão de root.

su foi a ferramenta original, exige que você digite a senha do usuário / grupo para o qual está mudando.

sudo é mais recente e exige, por padrão, que você insira sua própria senha, mas pode ser configurado para aceitar a senha do usuário / grupo para o qual está mudando ou nenhuma senha. Ele também permite muita configuração, de quais comandos ele irá trabalhar, para quem e como ele será autenticado com este programa para este usuário nesta máquina. Há também sudoedit que faz parte de sudo e pode ser usado para permitir a edição como um usuário diferente e evitar o problema de segurança de sub-descarte de um editor (chamando exec do editor para executar um processo arbitrário com escalada privilégios).