Forçando o proprietário nos arquivos e pastas criados

Eu tenho um diretório que contém dados compartilhados entre vários usuários. O acesso a este diretório e a qualquer coisa abaixo dele será controlado pelo grupo do diretório, que será adicionado aos usuários em questão. Como tal, criei o conjunto de pastas "sticky group" chmod g+s. O diretório conterá uma estrutura em árvore com diretórios e arquivos, com a quantidade total de arquivos provavelmente sendo de alguns milhões. Os arquivos serão bem pequenos, não prevejo nada maior que 50 MB.

Meu problema é que o proprietário do arquivo ou diretório ainda é o usuário que o criou. Como tal, mesmo que eu devesse remover esse usuário do grupo de acesso, não o removeria completamente.

Tão:

Há outras opções que eu perdi para garantir que todos os arquivos e subdiretórios tenham o mesmo proprietário?

Eu espero que possa navegar periodicamente por todo o diretório com um cron-job, mas isso me parece ineficiente para o que é essencialmente um comando de uma vez por arquivo.

Encontrei um exemplo usando o INotify, mas isso me parece de alta manutenção, pois requer scripts.

Não consegui descobrir se a ACL pode me ajudar com a propriedade forçada.

Existe uma maneira mais inteligente de fazer isso?

O que eu quero é ter um diretório que possa ser compartilhado adicionando um grupo a um usuário. Qualquer coisa criada neste diretório herda o esquema de permissão de seu pai. Se existe uma maneira melhor do que estou tentando, sou todo ouvidos.

Definir um proprietário padrão "automaticamente" exigiria que um diretório setuidse comportasse como setgid. Entretanto, embora isso possa ser configurado no FreeBSD, outros sistemas UNIX e Linux simplesmente ignoram u+s. No seu caso, no entanto, pode haver outra solução.

O que eu quero é ter um diretório que possa ser compartilhado adicionando um grupo a um usuário. Qualquer coisa criada neste diretório herda o esquema de permissão de seu pai. Se existe uma maneira melhor do que estou tentando, sou todo ouvidos.

Então, basicamente, pelo que vejo, você deseja controlar o acesso a um diretório usando o mecanismo de grupos. No entanto, isso não requer que você restrinja as permissões em toda a estrutura de diretórios. Na verdade, o --xbit de execução do diretório pode ser exatamente o que você precisa. Deixe-me lhe dar um exemplo. Assumindo que...

• O grupo que controla o acesso ao group_dirdiretório é ourgroup.
• Somente pessoas do ourgroupgrupo podem acessar group_dir.
• user1e user2pertence a ourgroup.
• O umask padrão é 0022.

... considere a seguinte configuração:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Aqui, vamos assumir que cada item foi criado por seu proprietário.}

Agora, nesta configuração:

• Todos os diretórios podem ser navegados livremente por todos os usuários ourgroup. Qualquer pessoa do grupo pode criar, mover, excluir arquivos em qualquer lugar dentro group_dir(mas não em profundidade).
• Quem não ourgroupestiver dentro será bloqueado group_dire, portanto, será incapaz de manipular qualquer coisa sob ele. Por exemplo, user3(quem não é membro ourgroup), não pode ler group_dir/user2_submission/README(mesmo que ele tenha r--permissão no próprio arquivo).

No entanto, há um pequeno problema neste caso: devido ao umask típico, os itens criados pelos usuários não podem ser manipulados por outros membros do grupo. É aqui que as ACLs entram. Ao definir as permissões padrão, você garantirá que tudo esteja bem, apesar do valor umask:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

Esta chamada define:

• rw(x)Permissões padrão para o proprietário.
• rw(x)Permissões padrão para o grupo.
• Por padrão, não há permissões para os outros. Observe que, como os outros não podem acessar de group_dirqualquer maneira, não importa realmente quais permissões estão abaixo dele.

Agora, se eu criar um item como user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

Com essa ACL, podemos tentar reconstruir nossa estrutura anterior:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Aqui, novamente, cada item é criado por seu proprietário.}

Além disso, se você quiser dar um pouco mais de energia / segurança para aqueles que usam o diretório, considere um pouco complicado. Isso impediria, por exemplo, a user1exclusão user2_submission(já que ele tem -w-permissão group_dir):

$ chmod +t group_dir/

Agora, se user1tentar remover user2o diretório, ele ficará adorável Operation not permitted. Observe no entanto que, embora isso impeça modificações na estrutura de diretórios group_dir, os arquivos e diretórios abaixo ainda estão acessíveis:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

Outra coisa a considerar é que as ACLs que usamos configuram permissões padrão . Portanto, é possível que o proprietário de um item altere as permissões associadas a ele. Por exemplo, user2pode executar perfeitamente ...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... portanto, tornando seu diretório de envio completo indisponível para qualquer pessoa do grupo.

No entanto, como você originalmente deseja dar rwsacesso total a qualquer pessoa do grupo, presumo que você confie nesses usuários e que não esperaria muitas operações maliciosas deles.

Existe uma maneira mais inteligente de fazer isso. Ele usa uma combinação de set-gid e acls padrão . Obviamente, você precisará de um sistema de arquivos habilitado para acl. Vamos supor que o diretório em que você deseja compartilhar esteja /var/grpdire que os membros do grupo sharingpossam acessá-lo.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

As ACLs padrão são herdadas pelos subdiretórios criados em um diretório com ACLs padrão. Portanto, isso significa que qualquer arquivo criado /var/grpdirterá seu grupo definido sharingpelo bit setgid do diretório. Além disso, ele herdará as acls padrão, que substituirão as premissas padrão do estilo linux, porque não especificamos ACLs com usuários ou grupos específicos. Isso significa que todos os arquivos serão criados com propriedade <user>:sharinge permissões rw-rw----. Os diretórios serão os mesmos, exceto que eles também terão suas próprias ACLs padrão definidas como iguais aos pais ( /var/grpdir) e, é claro, os bits executáveis ​​definidos para usuário e grupo. Se você remover um usuário do sharinggrupo, ele não poderá acessar o diretório (nem nenhum arquivo nele, mesmo que seja o proprietário).

Diferentemente da correção periódica de permissões com um cronjob, as permissões estão sempre sincronizadas, pois são atualizadas automaticamente com os arquivos e diretórios criados recentemente. Esta solução é leve; não são necessários daemons e não há aumento no IO enquanto corrige as permissões de uma só vez.

Não conheço nenhuma boa maneira de fazer isso. A maneira tecnicamente mais limpa seria um sistema de arquivos FUSE que faça isso. Claro, muito trabalho se ninguém fez isso ainda.

Alternativas:

1. Use samba. samba tem o force userparâmetro Você pode exportar um diretório localmente e montá-lo localmente. Não torna os acessos mais rápidos, mas pode ser aceitável, pois apenas a rede de loopback está envolvida.

2. Use um sistema de arquivos não Linux como o FAT32. Isso deve ser configurado para um determinado usuário para montá-lo. As permissões de acesso devem ser tratadas pelo diretório pai.

Não ouvi nenhuma maneira de alterar automaticamente a propriedade de um arquivo, de forma que o proprietário do arquivo seja alterado quando o arquivo for movido para um determinado diretório. O mais próximo é o pouco complicado, mas parece que você indicou que a propriedade do grupo não é suficiente; a propriedade real do usuário precisa mudar.

Nesse caso, acho que sua melhor aposta é o trabalho cron com a bandeira chown -R, como Pandya mencionou. Coloque-o em um cron para executar a cada minuto ou a cada cinco minutos.

Se você pode explicar como seus usuários estão usando isso, pode haver uma solução melhor.

A ACL pode ajudá-lo a obter um controle mais detalhado sobre quem tem permissão para fazer o que, não mudará automaticamente a propriedade real do arquivo para você. Acho que você precisa ter uma visão mais elevada e avaliar / redesenhar sua solução nessa base.

Você pode usar o inotify-tools e escrever um script simples do bash como abaixo. O Inotify manterá seus olhos no diretório web e fará algo sempre que um evento como a criação de dir ocorrer dentro do diretório web. Existem muitos eventos existentes. Você pode pesquisar no Google ou procurar neste site

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done