Como posso saber se tenho permissão para executar um comando específico?

18

Existe alguma maneira de identificar se eu, como usuário comum, tenho o direito de emitir um comando.

Por exemplo; Quero verificar se tenho o direito de emitir o comando shutdown antes de realmente emiti-lo.

Algo como os seguintes comandos

-> doIhaveRightToIssue shutdown
-> Yes/No
    
por Bernhard Colby 21.03.2017 / 15:28

5 respostas

24

O caso mais simples é o de um executável binário como gzip . Primeiro, localizamos o executável:

$ which gzip
/bin/gzip

Em seguida, analisamos os atributos deste arquivo:

$ ls -l /bin/gzip
-rwxr-xr-x 1 root root 98240 oct 27  2014 /bin/gzip

Os três xs nos dizem que o arquivo pode ser executado pelo proprietário (o primeiro root ) ou qualquer pessoa no grupo root (segundo root ) e qualquer outra pessoa, respectivamente. Então, seu usuário tem permissão para executar o programa.

No entanto, seu executável pode ser um arquivo de script que chama outros executáveis ​​dentro dele. Você pode executar o script, mas não os programas chamados dentro dele. Não há como determinar se o usuário tem permissão para fazer isso, a não ser tentar de verdade.

Depois, há casos especiais como shutdown - este é realmente um link simbólico para um utilitário central chamado systemctl , que tem seus próprios mecanismos para determinar se você pode chamá-lo e pedir seu sudo senha se você não fizer isso, por exemplo.

(Sobre o comando which : localiza os executáveis ​​em seu $ PATH que você tem permissão para executar e diz qual deles você usa se tiver mais de um com o mesmo nome no $ PATH. localizar apenas qualquer executável.Eu o uso aqui como um exemplo de onde procurar a permissão.O fato de which encontrar o executável já indica que você tem permissão para executá-lo.

    
por Jos 21.03.2017 / 15:44
21

com sudo :

$ sudo -l shutdown
/sbin/shutdown

Se eu não tiver permissão, sudo irá reclamar em vez de mostrar o comando.

Com o polkit, você verifica a ação que deseja executar:

$ pkcheck --action-id org.freedesktop.login1.power-off --process $$ -u --enable-internal-agent && echo yes
polkittemporary_authorization_id=tmpauthz1
yes

Encontrar a ação relevante é uma questão diferente.

    
por muru 21.03.2017 / 15:52
8

Você pode usar:

test -x $(command -v shutdown) && echo yes || echo no

command -v shutdown retorna o caminho para o comando shutdown . test -x verifica se esse caminho é executável para você.

Observe que, embora você possa executar o comando, o comando ainda poderá falhar porque tem permissão inadequada para executar a tarefa. Esse é o caso comum em sistemas do tipo Unix, que, em vez de restringir o acesso para executar um comando, restringe o acesso às operações que os programas podem realmente fazer.

    
por Robie Basak 21.03.2017 / 20:54
5

Bem, pode ser um pouco difícil às vezes ...

Primeiro, veja as permissões com ls -l ...

 owngrpotr  user  group  command
-rwxr-xr-x  root  bin    vim

Se o último / terceiro tripleto tem um x ("pode ​​executar") nele, então outros - e isso significa que você - pode executá-lo ... Se é um shell-script ou algo assim, então outros também precisariam de r ("read").

Se outros não tiverem permissão de execução, mas grupo (o segundo trio), você poderá executá-lo se for um membro do > group - no exemplo acima, bin . Por exemplo, o grupo roda costuma ser usado para limitar quem pode executar su , de modo que somente usuários pertencentes a esse grupo possam executá-lo. Outro exemplo é criar um grupo para desenvolver e restringir a execução do compilador-C e de tais ferramentas para esse grupo.

Se houver um + à direita após o último trio, isso significa que AccessControllLists são usados ​​- isso pode adicionar direitos de execução a usuários e grupos adicionais.

+++

Mesmo que você seja capaz de executar o comando, o comando pode depender do acesso a arquivos, diretórios e / ou dispositivos aos quais você não tem acesso - isso pode limitar o que você poderá fazer (você pode não ser capaz de fazer nada).

Finalmente, embora possa ser permitido executar um comando, o próprio comando pode verificar sua identidade e recusar deixá-lo usá-lo, a menos que você esteja listado em um arquivo de configuração ou seja determinado usuário (por exemplo, root ). Por exemplo, o comando mount permitirá que root monte qualquer dispositivo - os usuários normais só têm permissão para montar dispositivos listados como tal em / etc / fstab ... o que pode não ser nenhum. Se você não estiver root e tentar montar algo, mount irá reclamar e se recusará a montar o dispositivo. Outro exemplo é o sudo , que será executado para qualquer pessoa, mas somente os usuários listados em / etc / sudoers poderão executar as coisas como root .

    
por Baard Kopperud 21.03.2017 / 19:27
3

Usar which , type , command etc. é uma solução prática que funcionará em 99% dos casos, mas com 100% de certeza você terá que inspecionar manualmente todos os diretórios executáveis ​​listados em seu diretório. %código%. Muitos shells (incluindo $PATH ) prefixarão seu comando com entradas de bash e tentarão executar esses arquivos repetidamente até que sejam bem-sucedidos. Como $PATH não pode realmente executar o comando, é impossível prever qual arquivo seu shell realmente escolherá.

Por exemplo, imagine que eu tenha which , ambos os diretórios contendo arquivos executáveis, mas para arquiteturas diferentes. A execução de PATH=/opt/arm/bin:/bin retornará which dd (supondo que eu tenha permissões para executá-lo), já que essa entrada é a primeira. No entanto, quando eu executar /opt/arm/bin/dd no meu shell, dd será executado, porque /bin/dd falhará na execução. A mesma situação pode acontecer no caso de binários corruptos, bibliotecas perdidas, etc. No final, não há nenhuma maneira de saber se você será capaz de executar um comando ou não, além de tentar.

Outro aspecto é o que você considera "ter permissões". Como usuário, tenho permissões para executar /opt/arm/bin/dd , mas não rm ~/file . Novamente, não há maneira geral de saber isso sem inspeção manual, ou emitir o comando e observar os resultados.

    
por Dmitry Grigoryev 22.03.2017 / 16:04