Eu vou estar fazendo uma boa quantidade de trabalho PHP em breve, e estou interessado em aprender RoR, então eu instalei o Linux Mint 12 no meu VirtualBox.
O aspecto mais frustrante do switch, até agora, foi lidar com as permissões do Linux. Parece que não posso fazer nada de útil (digamos, digamos, copiar o tarball do Symfony2 do meu diretório de Downloads para o meu documento root e extraí-lo) sem posar como root via sudo.
Existe uma maneira fácil de dizer ao Linux para me dar acesso irrestrito a certos diretórios sem abrir todas as permissões?
Duas opções vêm à minha mente:
Possua o diretório desejado usando chown :
sudo chown your_username directory
(substitua your_username pelo seu nome de usuário e diretório pelo diretório que você deseja.)
A outra coisa que você pode fazer é trabalhar como root, contanto que você SAIBA O QUE VOCÊ ESTÁ FAZENDO . Para usar o root do:
sudo -s
e então você pode fazer qualquer coisa sem ter que digitar sudo antes de cada comando.
Em geral, trabalhe sempre como seu próprio usuário, a menos que você esteja fazendo algo com um impacto de todo o sistema.
Se houver arquivos que você deseja colocar em seu servidor da Web, trabalhe como seu próprio usuário e, em seguida, use sudo para soltar os arquivos na área de exibição da Web do seu sistema de arquivos. Normalmente, isso seria executado por um script de instalação e você executaria algo como sudo -u webmaster install-webserver-files ou melhor sudo -u webmaster git update (ou o sistema de controle de versão de sua escolha).
Se você estiver trabalhando em um servidor de desenvolvimento e quiser que seus arquivos fiquem acessíveis instantaneamente, crie um diretório na área do servidor da Web e torne-o possuído ou pelo menos gravável por você. Após essa operação única ( sudo chown … ou sudo -u webmaster setfacl … ), você não precisará de privilégios elevados para operações diárias.
Às vezes é conveniente permitir que vários usuários gravem em um diretório ou tenham permissões diferentes para vários usuários que não sejam o proprietário ou para vários grupos. As listas de controle de acesso oferecem essa capacidade. Vejo Problemas de permissões para o diretório compartilhado em um servidor ou Problema de permissão de script de backup .
Sempre foi minha ideologia que, como usuário, você possa fazer o que quiser no Linux e em todo o resto, sempre há sudo . sudo permite executar poucas coisas como alguns outros usuários, na maioria das vezes casos como root para administração do sistema. sudo tem sido um recurso de maior vantagem para delegar algumas das minhas tarefas e privilégios de rotina como usuário (root) para outros e ajudar a gerenciar meu tempo e os outros melhor sem elevar os privilégios além do que é necessário. Ao mesmo tempo, é minha confiança neles que mantém suas entradas presentes no arquivo de configuração sudoers . Não tenho certeza se isso poderia estar relacionado, mas o que posso dizer é que o sudo oferece uma perspectiva de segurança melhor de quem e o que eles podem fazer com seus privilégios de confiança. Mesmo que algo dê errado, eles são responsáveis. (Eu sempre posso fazer alguns sneaky peaky com sudoers log informações para encontrar os culpados também).
Meus caras sempre expressaram sua preocupação para mim que eles têm que digitar sudo para tudo o que eles queriam fazer com privilégios elevados no ambiente Linux. Aqui encontrei a mesma pergunta também.
Para ver as soluções e minha busca para encontrar as alternativas, deparei-me com Controles de acesso baseados em recursos RBAC mas em outro terreno de aventura de Solaris com ferramentas como pfexec etc. a abordagem é mais melhor porque isso manteria os privilégios dos usuários já elevados e confiaria na consciência e no estado de alerta do que os sysadmins desejariam fazer com seus privilégios.
Considerando as soluções disponíveis do RBAC e suas implementações no mundo Linux, me deparei com
SELinux link
grsecurity link
e enquanto houver outras implementações, eu as consideraria na primeira ordem da lista. Implementar o RBAC é muito trabalho em uma organização, especialmente quando há muitos usuários. O RBAC soaria uma solução melhor em ambientes homogêneos. No entanto, quando há instalações Unix heterogêneas na rede e o banco de dados do usuário é comum, isso talvez falhe. Já que o SELinux não é escalável / implementado no Solaris e as ferramentas RBAC / pfexec não são implementadas no Linux. Diferentes abordagens existem para fazer uma única coisa. Por exemplo: link
As instalações diferentes em toda a rede podem não suportar essa abordagem (no entanto, o openrbac pode ser considerado uma abordagem de implementação comum), como sudoers é uma abordagem de host único ou não é capaz de configuração centralizada na rede / domínio. /etc/sudoers precisa ser sincronizado toda vez que houver uma alteração. Além disso, há um requisito de base de conhecimento durante a operação do arquivo sudoers. É necessário entender o idioma da política da configuração dos sudoers para não cometer erros e permitir concessões. O RBAC pode oferecer uma abordagem centralizada até certo ponto, enquanto os perfis de segurança podem ser comuns, adicionar / remover um usuário da função concedida pode ser feito de um único local (que é o local onde as informações do usuário / passwd / grupo são armazenadas o domínio como LDAP, NIS ou AD). Isso também implicitamente exigiria a compreensão dos comandos necessários para operar no banco de dados RBAC, como smexec, smmultiuser, sendo poucos.
O Sudo pode oferecer mais abordagem multi-plataforma aqui, ainda que funcione em todas as plataformas Unix / like que oferecem os recursos setuid. Tanto sudo como RBAC conseguem dar aos usuários não-root alguns privilégios que podem ser feitos sem a própria senha root . O Sudo pode fornecer uma abordagem mais refinada / granular nos argumentos de linha de comando que podem ser usados durante a execução dos comandos e restringir-se apenas a qual comando com argumentos pode ser executado com privilégios elevados. Embora o RBAC possa restringir o uso dos comandos ou binários instalados, mas não tenha nenhum controle sobre os argumentos da linha de comando. A auditoria é muito melhor e incorporada ao ambiente RBAC, enquanto sudo , depende da configuração e das restrições de segurança (por exemplo, não conceder o shell e, particularmente, os hosts podem fazer login nos outros hosts sem problemas).
Estas são apenas algumas das diferenças que eu poderia citar e eu, pessoalmente, tenho uma inclinação para usar o sudo do que o RBAC, embora com as limitações mencionadas eu poderia vir a implementar alguns trabalhos ao redor. Até que todos os problemas sejam resolvidos pelo RBAC para melhorar a vantagem do sudo, eu não acho que o sudo irá embora, pois é simples.
Sim, faça o login como root, que lhe dá controle de acesso de superusuário.
Mesmo conceito no Windows, você pode entrar em seu terminal usando o administrador.
Eu colocaria o document root onde você está trabalhando, então você tem acesso total a ele.
Para evitar ter que digitar sudo toda vez que você instalar uma Gem, siga este artigo aqui: link
Eu também recomendo instalar o RVM para gerenciar versões do Ruby e do Rails. link
Isso tornará sua vida mais fácil quando você encontrar o host no qual deseja implantar seu aplicativo usando versões diferentes daquelas em que você desenvolveu.
Execute o comando.
sudo su root
Agora você poderá executar comandos como o usuário root. Seja cuidadoso! Qualquer comando executado será o usuário root. Você pode atrapalhar seriamente as coisas se você não for cuidadoso.
Ou você altera as permissões do diretório para permitir que seu usuário salve e edite arquivos.
Edite o arquivo / etc / passwd e conceda permissões de root ao usuário "yourUserName" alterando as IDs de usuário e grupo para UID 0 e GID 0:
yourUserName: 0: 0 :: / home / yourUserName: / bin / sh
Como apontado por outras respostas, a solução mais limpa é alterar a propriedade dos arquivos e diretórios aos quais você precisa acessar. Você pode, alternativamente, criar um novo grupo dedicado, alterar a propriedade do grupo dos arquivos e diretórios para esse grupo e definir a permissão de gravação do grupo para esses arquivos e diretórios. Por fim, defina o bit SGID nos diretórios de forma que, se você criar um novo arquivo, ele herde a propriedade do grupo do diretório que o contém (ou seja, o grupo dedicado).
usuário @ servidor: ~ $ sudo passwd root
[sudo] senha para usuário:
Digite a nova senha do UNIX:
Redigite a nova senha do UNIX:
passwd: senha atualizada com sucesso
usuário @ servidor: ~ $ su
Senha:
root @ server: / home / user #
Esse "#" não é uma coisa linda?
Eu uso "sudo" apenas uma vez para alcançar a capacidade de
user @ server: ~ $ su
Senha:
root @ server: / home / user #
para a vida do servidor.
Para torná-lo seguro novamente,
root @ server: / home / user # exit
saída
usuário @ servidor: ~ $
Os administradores de sistemas vêm fazendo isso há anos, quando o "sudo" não era parte da tendência mollycoddling.
Quando você faz isso, é sua responsabilidade cuidar, não minha.
Ian
Tags sudo permissions linux