Como evitar o uso do sudo ao trabalhar em / var / www?

159

Eu quero parar de usar sudo toda vez que eu trabalho em /var/www . Como eu posso fazer isso? Eu simplesmente quero colocar todos os meus sites neste diretório e trabalhar com eles sem muita dor.

    
por TaylorOtwell 01.06.2011 / 05:43
fonte

8 respostas

223

A maioria das respostas aqui não está escrita com a segurança em mente. É bom ter a sensação de que executar sudo de cada vez não é muito inteligente. Se você cometer um erro de digitação (por exemplo, ( não execute ) sudo rm -rf / var/www/dir ), você poderá acabar com o sistema.

Nota: A partir do Apache 2.4.7 / Ubuntu 14.04, /var/www foi movido para /var/www/html Ajuste os comandos nesta resposta de acordo.

Veja:

Más ideias:

  • chmod 777 (sagarchalise) - permite que qualquer pessoa com acesso ao seu sistema grave nos diretórios e arquivos e, assim, permita que o intruso execute qualquer código sob o www-data user
  • chgrp -R www-data $HOME (cob) - permite que www-data leia ou grave arquivos no diretório inicial. Isso não está mantendo em mente a regra de privilégio mínimo
  • chown -R $USER:$USER /var/www (kv1dr) - a menos que o mundo tenha permissões de leitura em /var/www , o servidor Web em execução sob www-data não poderá ler (exibir) os arquivos. Se o arquivo for um documento HTML simples acessível ao público, talvez não seja um problema se o mundo puder ler o arquivo. Mas se o arquivo é um arquivo PHP contendo senhas, é.

OBSERVAÇÃO : nas soluções abaixo, concedi privilégios de gravação em www-data . No entanto, /usr/share/doc/base-passwd/users-and-groups.txt.gz declara:

  

www-data

     

Alguns servidores da web são executados como www-data. O conteúdo da Web não deve pertencer a este     usuário, ou um servidor Web comprometido seria capaz de reescrever um site. Dados     escritas por servidores da web serão de propriedade da www-data.

Quando possível, não concede permissões de gravação ao grupo www-data . O www-data só precisa ser capaz de ler os arquivos para que o servidor da Web possa veiculá-lo. O único caso em que www-data precisa de permissões de gravação é para diretórios que armazenam uploads e outros locais que precisam ser gravados.

Solução 1

Adicione-se ao grupo www-data e defina o bit setgid no diretório /var/www , de modo que todos os arquivos recém-criados também herdem esse grupo.

sudo gpasswd -a "$USER" www-data

Corrigir arquivos criados anteriormente (supondo que você seja o único usuário de /var/www ):

sudo chown -R "$USER":www-data /var/www
find /var/www -type f -exec chmod 0660 {} \;
sudo find /var/www -type d -exec chmod 2770 {} \;

(ainda mais seguro: use 640 ou 2750 e manualmente chmod g+w file-or-dir que precisa ser gravável pelo servidor web)

Solução 2

Crie um symlink para cada projeto em seu diretório pessoal. Digamos que seu projeto está localizado em ~/projects/foo e você deseja que ele esteja em /var/www/foo , execute:

sudo ln -sT ~/projects/foo /var/www/foo

Se o seu diretório pessoal não tiver nenhum bit de execução (descer) definido para other (por motivos de segurança), altere o grupo para www-data , mas defina apenas o bit de execução (não ler escrever). Faça o mesmo com a pasta ~/projects , pois ela pode conter outros projetos além de www. (Você não precisa de sudo se já adicionou seu usuário ao grupo www-data .)

sudo chgrp www-data ~ ~/projects
chmod 710 ~ ~/projects

Defina o grupo como www-data on ~/projects/foo e permita que o servidor da Web leia e grave em arquivos e arquivos + diretórios e desça aos diretórios:

sudo chgrp www-data ~/projects/foo
find ~/projects/foo -type f -exec chmod 660 {} \;
find ~/projects/foo -type d -exec chmod 2770 {} \;

Ainda mais seguro: use 640 e 2750 por padrão e arquivos chmod e diretórios manualmente que precisam ser gravados pelo usuário do servidor web. O bit setgid deve ser adicionado somente se você quiser que cada arquivo recém-criado em ~/projects/foo seja acessível pelo grupo.

A partir de agora, você pode acessar seu site em http://localhost/foo e editar seus arquivos de projeto em ~/projects/foo .

Veja também

por Lekensteyn 01.06.2011 / 11:48
fonte
6

Em vez de armazenar meus sites em / var / www, coloco links para os sites que estão localizados na minha pasta pessoal. Eu posso editar livremente ou adicionar páginas aos meus sites. Quando estou satisfeito com as mudanças, transfiro o FTP para uma empresa de hospedagem na qual o meu nome de domínio está vinculado.

    
por fragos 01.06.2011 / 09:06
fonte
5

Don'ts

  • Não defina permissões de arquivo para 777 (gravável pelo mundo)

    Esta é uma falha de segurança significativa, especialmente se você habilitar scripts do lado do servidor, como o PHP. Processos não privilegiados não devem ser capazes de gravar em arquivos que possam afetar o site ou, no caso de script do lado do servidor ser usado, executar código arbitrário.

  • Não se inclua como membro do grupo www-data e atribua permissões de gravação

    O objetivo desse grupo é que ele é um grupo sem privilégios que os processos do servidor executam como. Eles só devem ter acesso de leitura aos arquivos do site sempre que possível, pelos mesmos motivos acima.

  • Não altere as permissões dos processos do Apache

    Os processos-filhos do Apache são executados como o www-data user e group por padrão, e isso não deve ser alterado. Esta é apenas uma maneira de não dar permissão de gravação ao sistema de arquivos.

    Em certas circunstâncias, você quer que seus scripts do lado do servidor consigam gravar em arquivos, caso em que somente esses arquivos devem ser gravados por www-data e cuidado deve ser tomado para garantir segurança.

Dos

  • Defina os arquivos que pertencem a você

    Se você é o único, ou o habitual, para modificar certos arquivos no site, faz todo o sentido apenas apropriar-se desses arquivos. Defina seu proprietário para <your username> .

    Você não precisa modificar as permissões do servidor para isso, pois o servidor continuará recebendo acesso somente para leitura mesmo quando os arquivos pertencerem a você.

  • Escolha um local adequado para hospedar os arquivos (usando o DocumentRoot )

    Se /var/www não fizer sentido, você pode colocá-los em outro lugar. Se eles forem específicos para o seu próprio desenvolvimento ou teste, você poderá colocá-los em seu diretório pessoal. Ou você pode configurar alguns diretórios em /srv .

  • Se você quiser dar acesso ao grupo , crie um grupo novo para o propósito

    Não reutilize um grupo de sistemas, pois eles são normalmente projetados para ter o acesso que têm atualmente, e não mais, por motivos de segurança.

por thomasrutter 24.11.2016 / 00:43
fonte
4

Se você tornar o / var / www gravável pelo seu grupo e se adicionar ao grupo, não precisará usar o sudo enquanto estiver seguro. Tente isto:

sudo adduser <username> www-data
sudo chown -R www-data:www-data /var/www
sudo chmod -R g+rw /var/www

Você deve poder editar /var/www/ arquivos sem problemas.

A primeira linha adiciona você ao grupo www-data , a segunda linha apaga todos os arquivos com propriedade confusa e o terceiro faz com que todos os usuários que são membros do grupo www-data possam ler e gravar todos arquivos em /var/www .

    
por Azendale 01.07.2011 / 02:41
fonte
4

É simples assim. Você não precisa habilitar o apache 'UserDir' (não recomendado) nem bagunçar grupos 'www-data' (grupo apache no caso do Fedora)

Basta criar o diretório do seu projeto dentro de /var/www/html

cd /var/www/html
sudo mkdir my_project

Depois é só chown o diretório do projeto para o seu usuário.

sudo chown your_username my_project

Agora você pode começar a trabalhar na pasta do seu projeto como um usuário comum com qualquer editor, IDE de sua escolha. Não há mais sudos :)

    
por reversiblean 06.08.2016 / 09:49
fonte
1

chmod in / var em www para permitir o acesso do proprietário e chown para garantir que você seja o proprietário. Provavelmente uma ideia estúpida, mas definitivamente funcionaria.

    
por Daniel 01.06.2011 / 05:59
fonte
1

Você pode iniciar uma sessão de www em um terminal por

sudo su www-data

Combinado com um prompt de cores diferentes *, para tornar mais óbvio que seja o shell de um usuário diferente e uma política sempre para colocar o xterm (e editor e tal) correspondente em - por exemplo - o desktop virtual 4 , para que você se acostume, para evitar confusão.

*) Para um prompt diferentemente colorido com um caractere diferente, crie um arquivo / etc / prompt como este:

# PROMPTING
#       When  executing  interactively, bash displays the primary prompt PS1 when it is ready to read a command, and the sec-
#       ondary prompt PS2 when it needs more input to complete a command.  Bash allows these prompt strings to be  customized
#       by inserting a number of backslash-escaped special characters that are decoded as follows:
#              \a     an ASCII bell character (07)
#              \d     the date in "Weekday Month Date" format (e.g., "Tue May 26")
#              \D{format}
#                     the  format is passed to strftime(3) and the result is inserted into the prompt string; an empty format
#                     results in a locale-specific time representation.  The braces are required
#              \e     an ASCII escape character (033)
#              \h     the hostname up to the first '.'
#              \H     the hostname
#              \j     the number of jobs currently managed by the shell
#              \l     the basename of the shell's terminal device name
#              \n     newline
#              \r     carriage return
#              \s     the name of the shell, the basename of %pre% (the portion following the final slash)
#              \t     the current time in 24-hour HH:MM:SS format
#              \T     the current time in 12-hour HH:MM:SS format
#              \@     the current time in 12-hour am/pm format
#              \A     the current time in 24-hour HH:MM format
#              \u     the username of the current user
#              \v     the version of bash (e.g., 2.00)
#              \V     the release of bash, version + patchelvel (e.g., 2.00.0)
#              \w     the current working directory
#              \W     the basename of the current working directory
#              \!     the history number of this command
#              \#     the command number of this command
#              $     if the effective UID is 0, a #, otherwise a $
#              \nnn   the character corresponding to the octal number nnn
#              \     a backslash
#              \[     begin a sequence of non-printing characters, which could be used to embed a terminal  control  sequence
#                     into the prompt
#              \]     end a sequence of non-printing characters
#
#       The  command  number and the history number are usually different: the history number of a command is its position in
#       the history list, which may include commands restored from the history file (see HISTORY below),  while  the  command
#       number  is  the  position in the sequence of commands executed during the current shell session.  After the string is
#
# colors:
# \[...\]   wird benötigt, damit die shell weiß, daß hier kein printable output ist, und die Umbrüche richtig plaziert.
#
# ANSI COLORS
CRE="\[
[K\]"
NORMAL="\[[0;39m\]"
# RED: Failure or error message
RED="\[[1;31m\]"
# GREEN: Success message
GREEN="\[[1;32m\]"
# YELLOW: Descriptions
YELLOW="\[[1;33m\]"
# BLUE: System messages
BLUE="\[[1;34m\]"
# MAGENTA: Found devices or drivers
MAGENTA="\[[1;35m\]"
# CYAN: Questions
CYAN="\[[1;36m\]"
# BOLD WHITE: Hint
WHITE="\[[1;37m\]"
#
# default:
# postgres, oracle, www-data
#
# PS1=$BLUE"machine]->"$NORMAL\w"$BLUE ø $NORMAL"
PS1=$BLUE"machine]:"$NORMAL\w"$BLUE > $NORMAL"
#
# root, stefan:
#
case "$UID" in
    '0')
        PS1=$RED"machine:"$NORMAL\w"$RED # $NORMAL"
    ;;
    '1000')
    PS1=$GREEN"machine:"$BLUE\w$YELLOW" > "$NORMAL
    ;;
#    default)
#    ;;
esac

e fonte de /etc/bash.bashrc , por exemplo.

Como ferramenta adicional para ajudar na distinção, você sempre pode editar seus arquivos com um alias 'edit' ou um symlink, que aponta, dependendo da sua identidade (taylor / www-data) para gedit ou mousepad, vim ou pico. Ou você pode usar diferentes perfis de editor, pelo menos no gedit você pode definir suas preferências para texto preto em branco ou branco em preto, por exemplo.

Eu só tenho essa política para trabalhar como root, por isso não tenho certeza de como será bom trabalhar com www-data. Combinado com ssh-sessions para hosts diferentes, que têm seus próprios prompts, isso não me impediu de ser às vezes errado, mas se isso acontece, eu percebo rápido, o que está errado, e isso acontece raramente.

nota: O script de prompt é parcialmente uma cópia da manpage do bash.

    
por user unknown 01.06.2011 / 17:49
fonte
0

Em esta página do meu site eu cubro os comandos para alterar a permissão em /var/www entre o apache e o pi usuário, mas é essencial

sudo chown -R pi /var/www

então um reinício do apache

sudo service apache2 restart
    
por Nathan Dickson 24.11.2016 / 00:27
fonte