Herdando a propriedade de arquivos no linux

1

Temos um problema contínuo aqui no trabalho. Temos muitos sites configurados em hosts compartilhados, nosso cms grava muitos arquivos nesses sites e permite que os usuários dos sites façam upload de arquivos, etc.

O problema é que, quando um usuário faz o upload de um arquivo no site, o proprietário desse arquivo se torna o servidor da Web e, portanto, impede que possamos alterar as permissões, etc. via FTP.

Existem alguns problemas, mas o que realmente precisamos é uma maneira de definir um proprietário fixo se isso for possível em novos arquivos e diretórios que são criados no servidor. Por exemplo, em vez de escrever o arquivo como usuário apache, o php assume o proprietário do diretório pai.

Não tenho certeza se isso é possível (nunca vi isso acontecer). Alguma idéia?

Obviamente, não obteremos um login para o apache no servidor, e duvido que possamos entrar no grupo do apache também.

Talvez precisemos de uma maneira de permitir que o apache defina pelo menos o grupo de um arquivo, dessa forma poderíamos definir o grupo para o nosso usuário ftp no php e definir 664 e 775 para quaisquer arquivos que sejam gravados?

Felicidades, João.

    
por John Hunt 13.01.2011 / 06:32

5 respostas

5

As ACLs POSIX permitem definir ACLs herdáveis. Se você definir a acl padrão para um diretório, isso é herdado na pilha conforme novos arquivos são criados.

$ sudo mkdir /tmp/acltest
$ ls -ld /tmp/acltest 
drwxr-xr-x 2 root root 4096 2011-01-13 20:39 /tmp/acltest
$ touch /tmp/acltest
touch: setting times of '/tmp/acltest': Permission denied

Neste ponto, meu usuário (daniel) não pode criar arquivos neste diretório. Eu defino a acl padrão para o diretório, bem como a configuração de um usuário acl no diretório superior (o padrão se aplica a arquivos / diretórios criados neste diretório, não ao diretório propriamente dito)

$ sudo setfacl -m d:u:daniel:rwx /tmp/acltest/
$ sudo setfacl -m u:daniel:rwx /tmp/acltest/

E agora, posso criar um arquivo:

$ touch /tmp/acltest/foo
$ ls -la /tmp/acltest/foo 
-rw-r--r-- 1 daniel daniel 0 2011-01-13 20:41 /tmp/acltest/foo

Além disso, posso fazer o que quiser em arquivos que outros usuários criem nesse diretório:

$ sudo mkdir /tmp/acltest/foo2
$ ls -ld /tmp/acltest/foo2
drwxrwxr-x+ 2 root root 4096 2011-01-13 20:49 /tmp/acltest/foo2
$ sudo touch /tmp/acltest/foo2/bar
$ ls -la /tmp/acltest/foo2/bar 
-rw-rw-r--+ 1 root root 0 2011-01-13 20:43 /tmp/acltest/foo2/bar

As permissões normais de unix não permitem que eu toque nisso, no entanto, as ACLs dizem o contrário:

$ getfacl /tmp/acltest/foo2/bar
# file: tmp/acltest/foo2/bar
# owner: root
# group: root
user::rw-
user:daniel:rwx         #effective:rw-
group::r-x          #effective:r--
mask::rw-
other::r--

Note que este arquivo está dentro de um subdiretório do diretório / tmp / acltest, e assim as permissões normais do unix não me deixam fazer nada com este arquivo.

E, de fato, o usuário daniel pode fazer o que quiser com esse arquivo:

$ mv /tmp/acltest/foo2/bar /tmp/acltest/foo2/bar2
$ ls -la /tmp/acltest/foo2/
total 8
drwxrwxr-x+ 2 root root 4096 2011-01-13 20:49 .
drwxrwxr-x+ 3 root root 4096 2011-01-13 20:43 ..
-rw-rw-r--+ 1 root root    0 2011-01-13 20:43 bar2

Observe que os acls padrão só serão propagados à medida que novos arquivos e diretórios forem criados. Você precisará fazer uma operação de conjunto recursivo uma vez para definir tudo no lugar e, em seguida, sua ACL padrão assumirá.

Para acls do usuário, você precisa ter certeza de que seu sistema de arquivos está montado com a opção acl em / etc / fstab.

As ACLs POSIX TL; DR permitem definir permissões de usuário / grupo fixas que se propagam por uma árvore do sistema de arquivos.

EDIT: Formatação e opção de montagem

    
por 13.01.2011 / 08:57
1

acls são potencialmente muito perigosos - e o suporte varia. Uma solução melhor seria usar o grupo sticky bit e tornar os arquivos graváveis pelo grupo.

The problem is that when a user uploads a file on the site the owner of that file becomes the webserver and therefore prevents us being able to change permissions etc via FTP.

Isso não faz sentido - como um usuário pode se tornar um servidor web? Ou você está tentando descrever o que está acontecendo com safe_mode do PHP com o gid checking desabilitado? Nesse caso, a solução provavelmente é usar bity de grupo fixo com safe_mode_gid, no entanto, a funcionalidade safe_mode é deperecada e você deve estar procurando por uma solução diferente que não dependa dela.

a lot of websites set up on shared hosts

Você tem acesso root aos hosts? Se não, então você deve considerar migrar para um host dedicado ou virtual, onde você pode realmente controlar essas coisas - se você não pode alterar a configuração, então a opção somente é usar contas compartilhadas.

Você também deve continuar usando o FTP - é um pesadelo de segurança e é muito difícil de automatizar.

    
por 13.01.2011 / 11:36
0

A única maneira que eu já resolvi este tipo de problema é ter o root executando um cronjob regular que define as permissões nos arquivos no diretório do servidor web. Isso é meio feio mas funciona bem.

    
por 13.01.2011 / 06:42
0

Você pode usar a configuração umask para o apache.

link

Por padrão, os arquivos enviados usando o Apache interditarão a configuração do umask do servidor.

Mas você tem a opção de definir umask especificamente para o Apache.

Confira este link

    
por 13.01.2011 / 06:48
0

Em vez de executar cronjobs para alterar a propriedade, você pode usar o fsniper: link

O fsniper monitora diretórios para novos arquivos (por meio de inotify) e aciona scripts instantaneamente, em vez de periodicamente.

    
por 13.01.2011 / 08:22