Sudo vs root; Quaisquer diferenças reais?

Question

Estou trabalhando com um membro de suporte para um produto e ele insiste que eu preciso ser root para instalar uma série de patches, e que o sudo não funcionará; ele não fornece uma razão, mas parece muito firme em suas crenças. Navegando no Superusuário Eu não posso determinar qualquer razão possível para este ser o caso, e na confirmação, quando eu corro:

sudo -l

Eu recebo:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

Obter acesso da equipe do Linux / servidor para realmente ser root não é um processo imediato, como eu entendo, então prefiro instalá-los eu mesmo.

Existe algum motivo prático pelo qual o sudo se comportaria de maneira diferente do root para instalar software em um servidor?

    

Answer 1

Depende strongmente de como você chama seu programa com sudo ou su .
Por exemplo. no sistema em que estou neste momento:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1] 

Onde [1] = / usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin
Env = As variáveis de ambiente são redefinidas para 1 e 5, tiradas de $ USER em 2,3,4.

Assim, um script ou um programa que é iniciado com uma opção diferente pode ver diferentes $PATH , $HOME , seu shell pode ler diferentes variáveis .bashrc , .profile e Environment. Ele lê o arquivo relacionado com o $HOME . Cada usuário pode modificar seu ambiente de maneira diferente (variáveis, $PATH , .bashrc, .profile, .bash_profile, alias ...). Em particular, um utilizador pode ter uma ordem diferente dos diretórios no seu $PATH e, como consequência, um script pode executar um comando, e. em /home/$USER/bin , em vez do caminho esperado da raiz.

Você pode executar o programa em sudo -i porque estava logado como root com su - , mas você pode ter um comportamento diferente se você executá-lo com sudo MyCommand ou com su -c MyCommand .

De man su :

In the description part:
The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser
...
In the options part:
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

De man sudo

-i, --login
Run the shell specified by the target user's password database entry as a login shell. This means that login-specific resource files such as .profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed. sudo attempts to change to that user's home directory before running the shell. The command is run with an environment similar to the one a user would receive at log in. The Command Environment section in the sudoers(5) manual documents how the -i option affects the environment in which a command is run when the sudoers policy is in use.

    

Answer 2

Se você tiver acesso total a sudo , poderá se tornar root usando sudo su - , por isso o ponto de segurança é irrelevante .

De fato, há uma maneira de discernir a diferença entre um programa executado como root e um programa executado em sudo - usando getuid vs geteuid - mas este é um truque inventado. Por que um sistema de correção faria isso?

    

Answer 3

Existem algumas diferenças se você estiver obtendo um shell de root, como apontado pelo @Hastur.

Se você não estiver obtendo um shell de root, haverá mais diferenças. O membro de suporte pode ter experiência em tentar fazer coisas como sudo patch -p0 < /root/patch.file , em que patch é executado como root, mas < (canalização de um arquivo) não é.

    

Answer 4

Acredito que ao usar o sudo access, um arquivo de log é criado, no entanto, quando executado diretamente através do acesso root, não existe.

    

Answer 5

Depende da granularidade desejada para o acesso root. Se você tiver vários usuários que executam tarefas diferentes em um sistema, o sudo seria o ideal. Um exemplo que uso com frequência é a necessidade de reiniciar um aplicativo ou banco de dados. A segurança é sempre melhor feita pelo menos privilegiada. Eu uso grupos e só permitem que esses grupos executem ações explícitas. Um bom livro que descreve este processo é o "Domínio do Sudo: Controle de Acesso do Usuário para Pessoas Reais". Na verdade, é um bom livro sobre o sudo em geral ...