Usando sudo no openSUSE sem realmente mudar para usuário root (por exemplo, como no Ubuntu)

Question

Recentemente comecei a experimentar o openSUSE 12.3 depois de ter usado o Ubuntu por alguns anos. Ainda estou me acostumando com o tratamento do su (e sudo ) do openSUSE versus o uso do sudo do Ubuntu. Eu tenho lido o manual do openSUSE, mas não consigo descobrir respostas para duas questões relacionadas:

1) Em uma pergunta anterior em link , perguntei sobre como escrever um arquivo gpg descriptografado temporariamente em /run usando o gpg --output flag para que o arquivo descriptografado nunca tocasse no disco rígido. A fim de escrever para /run , no entanto, eu precisava usar sudo no Ubuntu (ou seja, sudo gpg --output '/run/temporary_file_name' etc. ).

Quando tento fazer a mesma coisa no openSUSE (usando sudo ou su ), recebo uma mensagem de erro de gpg , presumivelmente porque o usuário root não pode ver as chaves gpg da minha conta de usuário. Pode este uso de '' sudo from Ubuntu, in which sudo seems to use the same preferences / gpg keys as the regular user, be replicated in openSUSE? I could use gpg etc. tee etc. ', eu suponho, mas isso parece incômodo se comparado ao modo de fazer as coisas do Ubuntu.

2) Eu tenho vários scripts bash do Ubuntu que requerem privilégios de root para algumas linhas, mas não todas (por exemplo, copiar arquivos que eu não quero que sejam de root, mas então instalar novos softwares, que requerem root privilégios). No Ubuntu, eu poderia apenas ter algumas linhas começando com sudo . O sudo some_command nem sempre parece funcionar no openSUSE. A melhor maneira de adaptar esses scripts para o openSUSE é usar su -c 'command' nessas linhas do script? Se eu usar su no script, o script para de funcionar depois que eu digito a senha do root.

Por favor, note que, enquanto eu estou perguntando sobre o openSUSE especificamente, esta questão presumivelmente se aplica a muitas distribuições não-Ubuntu.

    

Answer 1

Se o sudo preserva a variável de ambiente HOME ou a configura para o diretório inicial do usuário de destino depende de sua configuração (consulte o manual para obter detalhes). Não é o Ubuntu fazendo certo e o SuSE fazendo errado, ou vice-versa: há vantagens e desvantagens em ambas as escolhas. É o seu trabalho como roteirista para lidar com ambos os casos. A solução para (1) é executar sudo -H ou passar --homedir para gpg.

No entanto, executar gpg como root é definitivamente a abordagem errada. Isso dá ao gpg muitos privilégios e pode ter o privilégio de acessar ~/.gnupg dele (por exemplo, se o diretório pessoal do usuário estiver no NFS). Execute gpg como o usuário que possui a chave e faça com que ela imprima os dados na saída padrão. Piping into tee é o modo padrão de enviar para um arquivo que você precisa de privilégios especiais para escrever (não tenho a menor idéia do porquê de considerá-lo “desajeitado”):

gpg -d foo.gpg | sudo tee /run/foo

Se su ou sudo é necessário para se tornar root depende da escolha do administrador do sistema. Usuários diferentes na mesma máquina podem usar um ou outro. A menos que você controle a configuração em todas as máquinas nas quais você executará seu script, permita ambas as possibilidades (por exemplo, com uma opção passada para o seu script).

Se seus scripts funcionarem no Ubuntu com sudo , mas falharem em outras distribuições ou com su , talvez você esteja confiando em que o ambiente seja (quase) completamente redefinido. Essa é a configuração padrão de sudo no Ubuntu, mas outros sistemas podem se comportar de maneira diferente. Corrija seu script para que não dependa do ambiente que está sendo redefinido.

    

Answer 2

Essa é basicamente uma resposta à pergunta 1, pois a outra é uma pergunta à parte da qual não tenho tempo de fazer agora.

O Ubuntu utiliza alguns atalhos de segurança para atrair usuários típicos de desktops que não querem ou precisam da complexidade adicional da separação total de privilégios. No entanto, se você estiver manipulando dados tão sensíveis que não queira gravá-los em disco, não será um usuário desse tipo e não deverá ignorar a arquitetura de segurança padrão, implementando as regras sudo no estilo Ubuntu.

ATENÇÃO: Só porque você coloca algo na RAM não significa que ninguém mais pode chegar a ele. O culpado mais óbvio é a troca em disco, que pode acabar armazenando o conteúdo do que estava na RAM indefinidamente. Mas outros compromissos também são possíveis.

Então, se você tiver desativado sua partição de swap e considerar isso bom o suficiente:

Uma opção melhor do que escrever para / run é provavelmente criar sua própria montagem tmpfs de propriedade do usuário que vai usá-la. Por exemplo, se os seus IDs de usuário e grupo forem 500:

mount -t tmpfs tmpfs /home/jl/realtmp -ouid=500,gid=500

Este comando terá que ser executado como root , mas depois de aperfeiçoar essa configuração, você poderá adicioná-la ao seu fstab para torná-la permanente:

tmpfs   /home/jl/realtmp    tmpfs   uid=500,gid=500 0   0

    

Answer 3

Eu habilitaria o sudo. Isso é feito editando o arquivo / etc / sudoers e adicionando o usuário da linha ALL = (ALL) ALL. Com o usuário desejado. Isso tem que ser feito como root.