Questão Como especificar a qual proprietário / grupo uma pasta criada programaticamente pertence


Um pouco de primeiro plano: Estou fazendo um site Drupal em uma máquina com Windows 7. O Drupal possui um módulo de imagem que, em resumo, permite o armazenamento de imagens em cache. Quando você cria um estilo de imagem, o módulo cria um diretório. Por exemplo, se você criar um estilo my_image_style ele irá criar automaticamente uma pasta sites/default/files/img/styles/my_image_style/and/some/other/folders/beneath. No entanto, o diretório criado possui o proprietário: group Administrators:System com permissão d--------+. Tudo o mais, indo todo o caminho até a raiz é chrisrockwell:None. O Apache (essa é uma configuração do WAMP5) também é chrisrockwell:None.

O módulo Drupal precisa criar arquivos nesse diretório, mas não pode devido ao problema de permissões.

Então, nessa configuração, como especificar a qual usuário: o grupo ao qual um diretório criado pertence?

Eu não tenho certeza se isso tem um efeito, mas eu faço principalmente tudo dentro do cygwin (se movimentando, abrindo, vim).

Por favor, deixe-me saber se você precisar de informações adicionais, ou se isso é mais adequado em outro site.

UPDATE: Se eu chmod 777 o diretório do site inteiro, a única pasta que eu obtenho permissão negada é a pasta image_style que é criada pelo script do Drupal.


0


origem


Nota, d---------+ não significa que não há permissões; a + significa que há uma lista de acesso associada ao diretório que não pode ser exibido como permissões simples. - Darth Android
@DarthAndroid Estou pensando que tem a ver com o Windows ACL. Mesmo se eu chmod -R 777 o diretório inteiro, executando como administrador, as permissões ainda são -rw-r - r--. Eu não sei muito sobre o ACL, então estou tendo problemas de solução de problemas - Chris Rockwell
Eu fui tão longe a ponto de dar a todos os usuários, todos os grupos, controle total sobre este diretório em particular, sem sucesso. - Chris Rockwell


Respostas:


Comentários do Cygwin

Esta é uma solução alternativa, em vez de uma resposta.

Recentemente, tive problemas semelhantes com o Cygwin. A causa parece ser uma configuração incorreta em como os usuários e grupos do Windows são mapeados para usuários e grupos do cygwin. Especificamente, vi que a guia "Segurança" na caixa de diálogo "propriedades do arquivo" contém entradas "Grupo ou Nome de usuário", como OWNER e GROUP. Eu suponho que estes não são suportados pelo Windows.

Pode valer a pena olhar para o mkpasswd utilitário e lendo em janelas ACLs para resolver isso permanentemente. No entanto, até agora eu consegui me livrar de todos os erros de permissão de arquivos, redefinindo as ACLs do Windows para os padrões da seguinte forma:

wraptor: ~/tmp/su/find-xargs
$ icacls.exe . /reset /t
processed file: .
processed file: .\.search-dirs
processed file: .\.test
processed file: .\dirz
processed file: .\foo
processed file: .\moo
processed file: .\sensors
processed file: .\.test\test.java
processed file: .\dirz\3.java
processed file: .\foo\2.java
processed file: .\moo\1.java
processed file: .\sensors\light.java
Successfully processed 12 files; Failed processing 0 files

Depois disso, às vezes é necessário percorrer a hierarquia e redefinir os bits de permissão:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

Após essas etapas, os arquivos são "de propriedade" corretos do windows-me ou do usuário Administrador, e os programas nativos do Windows podem ler e gravar esses arquivos como de costume.


Tentativa de resposta

Além disso, umask deve ser mencionado. Ele é definido em um ambiente de usuários (ou para um processo em um programa) e controla as permissões de arquivos e pastas criados posteriormente.

por exemplo (bash)

umask 0022

Isso fará com que todos os arquivos e pastas sejam criados com as permissões 644 e 755.

por exemplo (python)

$ cat moo.py
import os
for _ in ('0022', '0002', '0077'):
        os.umask(int(_, 8))
        with open('moo.f-%s' % _, 'w') as f:
                f.writelines("moo\nfoo")

$ python moo.py; ll moo.f-*
-rw-rw-r-- 1 1K 2013-07-24 07:46 moo.f-0002
-rw-r--r-- 1 1K 2013-07-24 07:46 moo.f-0022
-rw------- 1 1K 2013-07-24 07:46 moo.f-0077

PHP tem um "idêntico" umask função.

Mais informações aqui: man 3p umask


0



Eu vou olhar para umask - obrigado. Seu trabalho resolveu meu problema atual e permite que eu volte a trabalhar neste módulo. Vou observar que eu tive que executar o .exe do cmd em vez do cygwin para que ele fosse afetado. Muito obrigado! - Chris Rockwell
Não mencione isso :) Se você descobrir o que está fazendo com que o Cygwin bloqueie as permissões do Windows, eu apreciaria um comentário. - Ярослав Рахматуллин


Eu vi problemas semelhantes com outros aplicativos no Windows definindo o grupo errado ao executar como administrador. Eu não sei como corrigir o problema de criação de diretório original, mas você pode reatribuir o proprietário e grupo para todos os diretórios no cygwin usando chown:

chown -R chrisrockwell:none my_image_style

1



Obrigado, eu já tinha chown'd o diretório. Mesmo que chrisrockwell: Nenhum é agora o proprietário: group, o módulo Drupal ainda não consegue ler / escrever. - Chris Rockwell