Minhas permissões para / usr / local / estão corretas?


88

Estou usando o HomeBrew para minhas necessidades de portas (parece um pouco "mais limpo" que o MacPorts).

Eu posso instalar sem sudoing (o que é ótimo), mas a etapa de vinculação do homem parece exigir isso ( /usr/local/share/man/man3pertence a root).
Um guia que encontrei sugere que eu recursivamente chown /usr/localfazendo

sudo chown -R `whoami` /usr/local

Isso é seguro ... ou é uma Bad Idea ™?

Além disso: minhas permissões estão corretas?

$ pwd
/usr/local/share/man
$ ls -lah
total 32
drwxrwxr-x    8 root  staff   272B  4 Set 11:02 .
drwxrwxr-x    9 root  staff   306B 10 Set 11:27 ..
drwxr-xr-x    3 root  wheel   102B  4 Ago  2009 de
drwxrwxr-x  163 root  staff   5,4K 10 Set 11:27 man1
drwxr-xr-x   11 root  wheel   374B 10 Set 11:27 man3
drwxr-xr-x    7 ago   staff   238B 10 Set 11:39 man5
drwxr-xr-x   11 ago   staff   374B 10 Set 11:39 man7
-rw-r--r--    1 root  staff    13K  4 Set 11:02 whatis

5
É assim que o Homebrew deve ser usado. Algumas pessoas podem discordar, mas o desenvolvedor líder diz para fazer as coisas dessa maneira.
Mike McQuaid

1
Ligeiramente melhor alternativa para o seu chown: sudo chown -R :admin /usr/local. Dessa forma, funcionará da mesma forma para qualquer usuário administrador da máquina. Embora você também precise executar sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+para garantir que o grupo tenha o mesmo acesso de gravação que o usuário.
Slipp D. Thompson

12
"Vou usar o homebrew, parece mais limpo que o macports. Oh, olhe essa bagunça de permissão mal definida. Vou verificar o Stack Overflow. Oh, aqui está um truque rápido que vai contra as melhores práticas do Unix e contra o que as atualizações do sistema operacional tentam para impor. Perfeito! ". Mês depois: "Ei, como esse malware foi instalado?"
hmijail

O problema que tenho com essa abordagem é que significa que apenas a conta de usuário que instala o Homebrew pode usá-la. Eu tenho um Mac com várias contas que uso para manter os projetos de trabalho separados dos projetos domésticos (por exemplo). Se eu estiver logado na conta errada, não posso usar a instalação do brew. Eu segui esse caminho para evitar os perigos do uso de root, mas não estou convencido de que seja a melhor abordagem.
Auspice

@MikeMcQuaid Acho interessante que Homebrew finalmente admitiu culpa sobre isso e na nova versão lançada uma ou duas semanas atrás, restabeleceu as permissões padrão para / usr / local
oemb1905

Respostas:


37

Geralmente, é melhor manter as permissões o mais rigorosas possível. Manter a /usr/localpropriedade por rootmeios que apenas processos executados como root/ sudo(ou solicitam usuário administrador por meio da caixa de diálogo de autorização da Apple) podem gravar nesta área. Assim, um download de processo precisa solicitar uma senha antes de corromper os arquivos.

Mas, como você diz, torna mais difícil adicionar novos programas.

Eu estou bem com a execução sudo, pois você instala as coisas com menos frequência do que executá-las, mas precisa confiar que o processo de compilação não muda o que deveria.

Se você quiser evitar o sudo, eu instalaria o Homebrew ~/usr/locale alteraria seu caminho, manpath etc para incluir os diretórios lá.

Uma maneira melhor é criar outro usuário - por exemplo, homebrewe criar um diretório de propriedade desse usuário. Em seguida, instale lá usando sudo -U homebrew. Outros usuários terão o benefício de não serem capazes de sobrescrever outros arquivos, porque não estão sendo executados root e outros programas não podem afetar o homebrew. (Observo que as Perguntas frequentes do Homebrew sugerem esse novo usuário se você estiver em um "ambiente multiusuário". Eu diria que qualquer máquina Unix, incluindo o macOS, é um ambiente multiusuário)

No entanto, como o wiki do Homebrew diz que as receitas não encontram todos os casos /usr/locale as substituem pelo diretório escolhido, suspeito que estamos presos /usr/local.


1
+1 para manter as autorizações rigorosas, alterar $PATHe $MANPATHincluir diretórios de usuários. Se os programas instalados não exigirem instalação em todo o sistema, é uma alternativa muito melhor.
zneak

3
+1 e resposta aceita para "manter as permissões o mais rigorosas possível". Fazer brew doctor(sugerido abaixo) me disse que só preciso exibir os diretórios compartilhados do homem ... suficientemente seguros para mim.
Agos 13/09

1
Uma solução de compromisso, pelo menos para as pessoas que cuidam da segurança o suficiente para não executarem como usuários Admin o tempo todo, é alterar a propriedade e as permissões do grupo para que somente os administradores possam gravar em / usr / local. Veja a resposta de kenorb.
Hmijail # 25/16

2
@ Marcos Acho interessante que Homebrew finalmente admitiu culpa sobre isso e na nova versão lançada uma ou duas semanas atrás, restabeleceu as permissões padrão para / usr / local
oemb1905

48

Também uso o Homebrew e posso confirmar que é totalmente seguro. Citando a página Instalação na FAQ oficial do Homebrew :

Faça um favor a si mesmo e escolha /usr/local

  1. É mais fácil
    /usr/local/bin já está no seu PATH.

  2. É mais fácil
    Toneladas de scripts de construção quebram se suas dependências não estiverem em / usr ou / usr / local. Nós corrigimos isso para as fórmulas do Homebrew (embora nem sempre o testemos), mas você verá que muitos scripts de configuração do RubyGems e Python quebram, o que é algo fora de nosso controle.

  3. É seguro A
    Apple está em conformidade com o POSIX e deixou esse diretório para nós. O que significa que não há /usr/localdiretório por padrão; portanto, não há necessidade de se preocupar com a bagunça das ferramentas existentes.

Se você planeja instalar gemas que dependem de cervejas, economize um monte de aborrecimentos e instale-o no /usr/local!

Não é trivial dizer ao gem para procurar em diretórios não-padrão por cabeçalhos e dylibs. Se você escolher /usr/local, tudo "simplesmente funciona!"

Vou apenas acrescentar que as coisas que fazem como root é uma idéia muito ruim , por isso chowning /usr/localnão só me parece razoável (não é um dir sistema on OSX), mas .

Suas permissões ainda não estão corretas. Basta executar o comando que você listou e você ficará bem.

Se você tiver outros problemas, lembre-se, o brew doctorpode ajudá-lo!


Comentários não são para discussão prolongada; esta conversa foi movida para o bate-papo .
Bmike

7
A conversa acabou, o que é uma pena. Portanto, correndo o risco de repetir a história, deixarei meu comentário aqui: que isso seja feito não significa que isso seja seguro.
hmijail

4
A essência do gráfico é que, embora este é o Homebrew sugere que há razões de por que isso está errado
user151019

1
brew doctoré simplesmente incrível.
Utku

5
@Carmine Paolino Acho interessante que Homebrew finalmente admitiu culpa sobre isso e na nova versão lançada uma ou duas semanas atrás, restabeleceu as permissões padrão para / usr / local
oemb1905

9

Se você estiver usando o Homebrew, conceda permissão de gravação a um grupo específico ( adminou staff), para que os arquivos possam ser compartilhados entre os usuários que estão nesse grupo.

Por exemplo:

sudo chgrp -R admin /usr/local /Library/Caches/Homebrew
sudo chmod -R g+w /usr/local /Library/Caches/Homebrew

Em seguida, atribua os usuários que devem ter acesso ao brewcomando para esse grupo (verifique seus grupos em:) id -Gn.

Então, ao trabalhar com brew, não execute-o com sudo.

Quando ainda tiver algum problema de permissão, execute brew doctorpara solucionar o problema.


+1 por fornecer uma solução real e com melhor comportamento, mesmo que não tenha sido realmente concluída. Por exemplo: adicione um usuário ao grupo de administradores no nível BSD? Isso não vai mexer com o conceito de usuários Admin do OS X?
hmijail

Para o registro, segui estas instruções, mas apenas usei meu usuário Admin existente, criado pela GUI do OS X, em vez de adicionar alguém a qualquer grupo na CLI. Funciona: para poder executar comandos de preparação, eu tenho que fazer primeiro su myAdminUsere depois tudo funciona conforme o esperado. Mas é claro que esta solução não dará nenhuma segurança para as pessoas que já estão executando um usuário Admin o tempo todo.
Hmijail # 25/16

Este é provavelmente o melhor caminho a seguir, concordo com @kenorb
pixel 67

7

Pelo que vale, /usr/localnão é considerada uma pasta "sistema" pelo OS X e, em uma nova instalação do Snow Leopard, essa pasta está vazia.

Qualquer coisa de propriedade raiz nessa pasta é resultado de sudo make installoutro software, ou fornecer sua senha após clicar duas vezes na .pkgque deseja despejar coisas /usr/local.

A propriedade /usr/local"trabalhou para mim" em 2 máquinas por mais de um ano.

Um problema é que, se você instalou o MySQL (sem usar o Homebrew) e reproduziu seus arquivos, provavelmente não poderá mais ver seus bancos de dados (então você terá que reproduzi-los de volta para qualquer usuário que o MySQL esteja executando como .)


5
gcc e outras ferramentas de desenvolvimento se parecem automaticamente em / usr / local para que ele afeta o sistema
user151019

11
O problema não é que seja uma pasta "sistema"; é que é uma pasta "em todo o sistema". Mesmo se não houver nada lá, /usr/local/binainda está no $PATHvalor padrão e o que você colocar lá também pode ser usado por outros usuários e deve ser confiável . Se o /usr/local/diretório inteiro tiver as mesmas permissões /usr/local/share/manatualmente disponíveis na configuração do OP, qualquer pessoa poderá alterar qualquer binário com um script que o faça rm -rf ~.
Zneak 10/09/10

1
muito arriscado: é provável que eu instale o MySQL mais cedo ou mais tarde #
1313 Agos

2
@ Agos: você sempre pode instalar o MySQL com o HomeBrew; nesse caso, você não terá nenhum problema :) #
Carmine Paolino

1
@ Agos Não é arriscado. O cuidado se aplica somente se você instalou o MySQL antes do Homebrew. Se você fizer isso depois, as permissões /usr/localdevem estar bem. (Mas você provavelmente usar Postgres qualquer maneira :).)
Marnen Laibow-Koser

6

Como no Homebrew 1.0.0:

O Homebrew não precisa mais ter propriedade de / usr / local. Se desejar, você pode retornar / usr / local para a propriedade padrão com: sudo chown root: wheel / usr / local


1
Atualmente, estou atualizando o Brew usando brew update, o que ainda exige a propriedade /usr/local. Vou tentar restaurar as permissões posteriormente.
Joshua Pinter

Esta é realmente uma ótima informação! Eu configurei permissões conforme especificado pelo Homebrew (<1.0) e, após a atualização, deu essas instruções sobre como recuperá-las.
Mortona42 4/17

0

Acho que não há problema em os usuários terem permissões de gravação para /usr/local- afinal, isso significa que você não está usando sudoem todos os scripts de compilação. Não gosto da ideia de um usuário comum possuir /usr/local . Eu preferiria ter raiz (ou similar) /usr/local, mas altere as permissões para que os usuários (ou pelo menos algum grupo privilegiado) possam gravar nele. Essa parece ser a abordagem conceitualmente correta.


7
O problema aqui é que /usr/local/binpode muito bem estar na frente de $ PATH para a maioria dos usuários. Tornar o diretório gravável mundialmente abre muitas brechas de segurança dessa maneira.
nohillside

@patrix Então mude os caminhos. :) Se você tiver scripts com falhas de segurança devido a caminhos de comando ambíguos, eu culparia os scripts, não suas permissões - os comandos invocados nos scripts geralmente devem ser totalmente qualificados exatamente por esse motivo. De qualquer forma, não há solução melhor: você dá à sua conta de administrador uma umask insegura ou executa todos os seus scripts de compilação sudoou dá permissão a alguns usuários de gravação /usr/local. Vou considerar o terceiro como sendo menos arriscado ... a menos que você saiba de uma maneira melhor.
Marnen Laibow-Koser

Hmm. Pensando nisso um pouco mais, talvez uma maneira melhor seria fazer o Homebrew fazer o que o RVM faz por padrão: instalar tudo ~/brewou algo assim. O problema, porém, é que ao contrário de Ruby, que é bastante auto-suficiente, um monte de * nix utilitários esperar encontrar uns aos outros em /usr/local...
Marnen Laibow-Koser

3
Esqueci de mencionar que /usr/localnão é gravável em todo o mundo: em vez disso, tenho um grupo confiável homebrew(não apenas o administrador) que possui permissões de gravação (permissões estendidas, como 0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inherittotalmente rock). Este é o melhor compromisso que consegui descobrir: não sudoem scripts de construção, mas em algum controle /usr/local.
Marnen Laibow-Koser

@ MarnenLaibow-Koser Gostaria de ver uma explicação mais aprofundada dessa abordagem (criando um grupo confiável de usuários com permissões de gravação /usr/local). Pesquisando muito em SO e em outros sites, vendo argumentos sobre: ​​mover o Homebrew para a pasta inicial do usuário versus manter-se /usr/local, mudar de proprietário e / ou grupo /usr/localou não, e assim por diante ... é difícil dizer se há algum solução universalmente aceitável. Você tem um post ou artigo sobre isso, ou poderia dar uma explicação mais profunda em algum lugar?
Gabriel L.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.