É seguro chown '/ usr / local'?

Question

Eu sei para que /usr/local é - instalar software para a máquina local. Por padrão, root possui o diretório. Isso significa que para instalar lá, você precisa usar sudo . Para uma máquina de usuário único ou de desenvolvedor, isso parece um uso extra desnecessário do comando. Por isso, minha pergunta - é seguro para eu possuir o /usr/local ?

Por exemplo, Homebrew para OS X "Just Works" porque eles possuem /usr/local e seguramente instalam seu software lá sem o uso de sudo .

Além disso, se você tiver um software compilado localmente instalado em /usr/local , o software precisa atualmente que a raiz modifique a si mesmo ou instale plug-ins. Isso parece inseguro - quero usar somente sudo quando souber EXATAMENTE o que acontecerá.

Opiniões?

    

Answer 1

Não posso recomendar que você se torne o proprietário de /usr/local ; para a maioria das situações, é provavelmente menos seguro do que usar sudo .

Sua pergunta sugere dois motivos pelos quais você pode querer chown /usr/local .

O primeiro é evitar o uso do sudo para instalar o software. Isto pode ler para alguns (como o autor de esta resposta ) dizendo que você quer trabalhar de forma eficiente, ou salvar as teclas digitadas necessário digitar sudo e digite sua senha. Mas, provavelmente, quando você diz "desnecessário", está se referindo ao princípio de menor privilégio :

  

Por padrão, root possui o diretório. Isso significa que para instalar lá, você precisa usar sudo . Para uma máquina de usuário único ou de desenvolvedor, isso parece um uso extra desnecessário do comando

Frequentemente ouço / leio pessoas opinando / reclamando ao longo das linhas de "Sou o único que usa esse sistema, então não preciso usar sudo e digitar uma senha". Para os leitores que são dessa opinião, e porque é relevante aqui, vamos nos lembrar de uma razão básica de segurança para a raiz ter as coisas.

A maioria dos arquivos de programa instalados em um sistema Ubuntu possui o modo de arquivo 755, ou em notação simbólica rwxr-xr-x , significando que qualquer usuário ou programa pode executá-los , mas somente o proprietário dos arquivos , root, pode modificá-los. (Tecnicamente, isso também exige que ninguém além do root tenha a permissão w no diretório que os contém, para que outros usuários não possam excluí-los ou movê-los.)

Isso significa que você, o usuário humilde, pode executar qualquer programa. Se você tentar usar um programa para fazer algo que você não tem permissão para fazer, como executar uma operação de gravação em um arquivo de propriedade do root, ele será executado com erro. Isso faz com que um erro de digitação em algum comando, um aplicativo com bugs ou código mal-intencionado, menos propenso a atrapalhar seu sistema - a menos que esteja sendo executado como root, ele não terá permissão para fazê-lo. Isso é especialmente útil ao executar programas que interagem com a Internet.

Se você chown /usr/local , qualquer programa executando com seus privilégios poderia gravar arquivos lá, que poderiam ser executados posteriormente como root por algum motivo, como substituindo outro comando da mesma nome. /usr/local/bin está no padrão $PATH e em sudo '< href="https://superuser.com/a/927599/105707"> secure_path e vem antes de outros locais em ambos. Então, se eu tiver dois executáveis

/usr/local/bin/chown
/bin/chown

quando executo sudo chown ... , o chown em /usr/local/bin será executado .

Mas você provavelmente já sabia disso, já que sua segunda razão é sobre segurança:

  

Além disso, se você tiver um software compilado localmente instalado em /usr/local , o software precisa atualmente que a raiz modifique a si mesmo ou instale plug-ins. Isso parece inseguro - quero usar somente sudo quando souber EXATAMENTE o que acontecerá.

_{Caso seja necessário mencionar isso aqui, é absolutamente correto (de acordo com o FHS) instalar o software compilado localmente em /usr/local , mas a própria compilação deve ser feita em algum lugar no seu $HOME , sem sudo , até a última etapa quando você digita sudo make install ou equivalente.}

Acho que você está sugerindo que, ao executar um programa instalado em /usr/local como seu proprietário sem privilégios, pode usar erros de permissão específicos ao tentar se atualizar para ver se está tentando modificar algum outro local do sistema de arquivos por você de uma maneira que você não quer, para que você possa impedir isso de fazê-lo.

Isso pode ser útil. A implicação é que você confia no programa para fazer o que quiser em /usr/local , mas não em outro lugar. Se ele solicitar permissões elevadas, você poderá se recusar a permitir sua atualização ou desinstalá-lo. Isso faz algum sentido para mim. Mas acho que tentar usar o /usr/local como uma espécie de sandbox dessa maneira provavelmente não é uma boa ideia, ou pelo menos é improvável que seja a solução mais segura. Não é um local isolado corretamente ( /opt é um pouco mais isolado, já que não está no padrão $PATH ). O programa pode gravar ou excluir algo em /usr/local para causar danos. Outros programas (potencialmente mal escritos) que você executa podem escrever e executar códigos que você não conhece.

Se você está preocupado em permitir que um programa se atualize de forma segura, provavelmente deve procurar alternativas (específicas para o programa, como o python, por exemplo, ou pode procurar uma implementação semelhante à sua necessidade) ou use contêineres ou uma VM para testar softwares potencialmente inseguros) antes de expor uma localização do sistema (mesmo que relativamente user-y) a ser gravada por programas executados por um usuário normal.Parece-me provável que tenha efeitos imprevisíveis, uma vez que permitir programas elevou temporariamente as permissões com sudo .

    

Answer 2

É incomum que /usr/local não seja de propriedade de root . Mas você pode mudar o dono como quiser.

Mas aconselho a garantir que /usr/local/sbin ainda seja de propriedade de root para evitar um problema de segurança. Os comandos aqui são geralmente chamados apenas por root.

    

Answer 3

Somente para o software você , use seu diretório pessoal em vez de /usr/local .

Em vez de alterar a propriedade de /usr/local ou de executar comandos como root quando você não deseja, você deve apenas configurar suas compilações para que elas sejam instaladas em seu diretório inicial, em vez de /usr/local . Isso resolve todos os possíveis problemas com a alteração da propriedade de /usr/local , incluindo como os subdiretórios bin e sbin estão no caminho root .

Se você precisar permitir que outros usuários executem seu software, você poderá conceder acesso a eles. Na verdade, eles provavelmente já poderão, porque, por padrão, seu diretório pessoal tem acesso permissivo de leitura e execução . (Se você não quiser isso, você pode mudá-lo facilmente, apenas usando chmod em qualquer arquivo ou diretório que você queira tornar privado e possivelmente também alterando seu umask .)

Com o software instalado em seu diretório inicial, os binários que teriam ido em /usr/local/bin serão colocados em /home/username/bin . Você obterá outros subdiretórios de seu diretório pessoal correspondentes aos subdiretórios de /usr/local que o software que você instalou precisa. Isso geralmente acontece automaticamente quando você instala o software a partir do código-fonte.

Configurando suas construções

A maioria dos softwares que você cria a partir do código-fonte tem uma etapa em que você executa:

./configure

Para a grande maioria dos softwares que vêm com um script configure que pode ser executado assim, o padrão é configurar a compilação para instalação dentro de /usr/local quando você eventualmente executa sudo make install para instalá-lo. A razão é que é implicitamente equivalente à execução:

./configure --prefix=/usr/local

Para configurar uma compilação para instalação em seu diretório inicial, use isso:

./configure --prefix="$HOME"

Na prática, no Ubuntu, os caminhos do diretório inicial não contêm espaços, outros espaços em branco ou outros caracteres que serão tratados especialmente pelo shell como * , portanto, a menos que você tenha configurado sua conta de usuário de forma bastante estranha, você pode simplesmente digitar:

./configure --prefix=$HOME

(Eu não recomendo ter o hábito disso para escrever scripts . Além disso, em alguns outros sistemas operacionais - como macOS - é menos incomum para os caminhos para os usuários diretórios iniciais para conter espaços.)

Ou, se preferir, você pode digitar o caminho completo do seu diretório:

./configure --prefix=/home/username

(Substitua username por seu nome de usuário real, é claro. Se por algum motivo o seu diretório home não estiver em /home , você terá que ajustar de acordo.)

Instalando seus Builds

Depois de executar make , você pode estar acostumado a executar sudo make install , mas quando você instala em seu próprio diretório pessoal, não precisa executá-lo como root, então você pode - e deve - omitir sudo . Basta executar:

make install

Da mesma forma, para softwares que suportam um uninstall target:

make uninstall

Isso é exatamente o que você estava pedindo ... apenas em seu diretório pessoal, não /usr/local .

Executando seus programas

Provavelmente o subdiretório bin do seu diretório pessoal é:

• já está no seu $PATH , ou
• estará no seu $PATH se você simplesmente sair e voltar.

A razão é que o arquivo .profile em seu diretório home, que contém comandos que são executados quando você efetua login, contém isto por padrão para contas de usuários criadas em a maioria das versões do Ubuntu (incluindo o conta de administrador inicial criada quando você instala o sistema operacional):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Esse código é executado quando você efetua login (porque está em .profile ) e coloca seu diretório pessoal bin em $PATH somente se ele existir naquele momento. É por isso que você pode precisar para sair e voltar.

Lançamentos mais antigos como Ubuntu 14.04, bem como lançamentos mais recentes como Ubuntu 17.10, vem com isso. No entanto, o Ubuntu 16.04, que é provavelmente o lançamento mais popular até o momento, tem isso:

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

Isso simplesmente adiciona o subdiretório bin do seu diretório pessoal - assim como o subdiretório .local/bin - ao seu $PATH , sem verificar se esses diretórios realmente existem. Portanto, se você usar 16.04, ou se você tiver atualizado de um sistema que foi 16.04 quando sua conta de usuário foi criada, o subdiretório bin de seu diretório inicial provavelmente já está no seu $PATH . / p>

Seu arquivo .profile é copiado do diretório /etc/skel quando sua conta de usuário é criada. Se sua conta de usuário foi criada em uma versão mais antiga do Ubuntu, ela obteve essa versão de .profile e não foi alterada - para sua conta de usuário - atualizando para uma versão mais recente.

Quando o subdiretório bin do seu diretório home estiver no $PATH , você poderá executar programas cujos arquivos executáveis estão instalados lá apenas digitando seus nomes, assim como você poderia fazer com programas instalados pelo pacote do Ubuntu gerenciador ou instalado dentro de /usr/local .

A opção .local

Você deve ter notado que o arquivo .profile padrão para contas de usuários criadas em algumas versões do Ubuntu, inclusive em 16.04, como descrito acima, adiciona não apenas $HOME/bin ao seu caminho, mas também $HOME/.local/bin . Se o seu .profile não adicionar isso, mas você quiser , você pode simplesmente editá-lo.

Embora frequentemente usado para armazenar configurações e dados em cache , você também pode instalar software dentro do subdiretório .local do seu diretório inicial. Você deve se sentir desinibido ao fazer isso, pois, do ponto de vista de usabilidade e segurança, --prefix="$HOME/.local" é semelhante a --prefix="$HOME" .

Lembre-se de que arquivos e diretórios que começam com . não são mostrados por padrão em navegadores de arquivos gráficos (use Ctrl + H para reexibir e mostrá-los) ou o comando ls (passe o sinal -A ou -a para mostrá-los). Isso pode não ser o que você quer, ou pode ser exatamente o que você quer. Esta é uma questão de preferência pessoal.

No entanto, observei que alguns gerenciadores de pacotes automatizados baseados na origem que criam e instalam software em seu diretório base usam $HOME/.local . Eu realmente não sei o quão comum isso é - espero investigar mais e atualizar esta resposta - mas você pode preferir usar apenas $HOME para coisas que você compila manualmente. Dessa forma, ficará claro de onde as coisas vieram. E se houver uma colisão, o software ainda coexistirá de forma aceitável.

Você também pode instalar deliberadamente algum software em $HOME/.local e outro software em $HOME . Você decide. Qualquer que seja o diretório bin aparece primeiro na sua variável de ambiente $PATH é aquele que um comando será executado, no caso de existirem comandos com o mesmo nome em ambos.

O crédito vai para Zanna e Videonauth para apontar erros em um versão anterior desta resposta, em relação a quais versões do Ubuntu têm o código padrão em .profile e ajudando-me a corrigi-los (veja também aqui ).

    

Answer 4

Se o sudo é um inconveniente, apenas atualize o / etc / sudoers para que você não tenha que digitar sua senha quando você executar o sudo. Eu acredito que é uma solução melhor do que mudar o dono do / usr / local.