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

Question

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

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

Então:

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

Espero que eu possa navegar periodicamente em todo o diretório com um cron-job, mas isso me parece ineficiente para o que é essencialmente um comando que já foi pr-file.

Eu encontrei um exemplo usando o INotify, mas as greves me como de alta manutenção, já que requer scripting.

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 eu estou tentando, eu sou todo ouvidos.

    

Answer 1

Definir um proprietário padrão "automaticamente" exigiria um diretório setuid se comportando como setgid . No entanto, enquanto isso pode ser configurado no FreeBSD, outros UNIX & Sistemas Linux apenas ignoram u+s . No seu caso, no entanto, pode haver outra solução.

What I want is to have a directory that can be shared by adding a group to a user. Anything created in this directory inherits the permission scheme from its parent. If there is a better way than what I’m attempting, I’m all ears.

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

• O grupo que controla o acesso ao diretório group_dir é ourgroup .
• Apenas as pessoas no grupo ourgroup podem acessar group_dir .
• user1 e user2 pertencem a ourgroup .
• A 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 supor que cada item foi criado pelo seu proprietário.}

Agora, nesta configuração:

• Todos os diretórios podem ser navegados livremente por todos em ourgroup . Qualquer pessoa do grupo pode criar, mover, excluir arquivos em qualquer lugar dentro de group_dir (mas não mais profundamente).
• Qualquer pessoa que não esteja em ourgroup será bloqueada em group_dir e, portanto, não poderá manipular nada sob ela. Por exemplo, user3 (que não é membro de 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 nesse caso: por causa da típica umask, os itens criados pelos usuários não podem ser manipulados por outros membros do grupo. É aqui que entram as ACLs. Ao definir permissões padrão, você garante que tudo esteja bem, apesar do valor umask:

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

Esta chamada define:

• Permissões rw(x) padrão para o proprietário.
• Permissões rw(x) padrão para o grupo.
• Nenhuma permissão por padrão para os outros. Observe que, como os outros não podem acessar group_dir , de fato, não importa quais são suas permissões abaixo dela.

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 implementada, 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, mais uma vez, cada item é criado pelo seu proprietário.}

Além disso, se você quiser dar um pouco mais de poder / segurança para aqueles que usam o diretório, você pode querer considerar um bit pegajoso. Isso impediria, por exemplo, que user1 excluísse user2_submission (pois ele tem -w- permissão em group_dir ):

$ chmod +t group_dir/

Agora, se user1 tentar remover o diretório user2 , ele receberá uma% Operation not permitted . No entanto, observe que, embora isso impeça modificações na estrutura de diretórios em group_dir , os arquivos e diretórios abaixo ainda estarã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 usam as permissões padrão . Portanto, é possível que o proprietário de um item altere as permissões associadas a ele. Por exemplo, user2 pode ser executado perfeitamente ...

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

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

No entanto, como você está originalmente disposto a conceder acesso total a rws a qualquer pessoa do grupo, presumo que esteja confiando nesses usuários e que não esperaria muitas operações maliciosas deles.

    

Answer 2

Existe uma maneira mais inteligente de fazer isso. Ele usa uma combinação de aclags set-gid e padrão . Obviamente, você precisará de um sistema de arquivos habilitado para acl. Vamos supor que o diretório que você deseja compartilhar esteja em /var/grpdir e que os membros do grupo sharing possam 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 por subdiretórios criados em um diretório com ACLs padrão. Portanto, qualquer arquivo criado em /var/grpdir terá seu grupo configurado como sharing pelo bit setgid do diretório. Além disso, ele herdará os acls padrão, que substituirão as premissions de estilo padrão do linux, porque não especificamos ACLs com usuários ou grupos específicos. Isso significa que todos os arquivos serão criados com a propriedade <user>:sharing e 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 as de seus pais ( /var/grpdir ) e, é claro, terão os bits executáveis definidos para usuário e grupo. Se você remover um usuário do grupo sharing , eles não poderão acessar o diretório (nem quaisquer arquivos nele, mesmo que sejam deles).

Ao contrário de corrigir periodicamente as permissões com um cronjob, as permissões sempre estão em sincronia, pois são atualizadas atomicamente com arquivos e diretórios recém-criados. Esta solução é leve; nenhum daemons é necessário, e não há pico para IO enquanto corrige as permissões de uma só vez.

    

Answer 3

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

Alternativas:

1. Use o samba. O samba tem o parâmetro force user . Você pode exportar um diretório localmente e montá-lo localmente. Não torna os acessos mais rápidos, mas pode ser aceitável, já que 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 manipuladas pelo diretório pai.

Answer 4

Eu não ouvi falar de nenhuma maneira de alterar automaticamente a propriedade de um arquivo, de modo que o proprietário do arquivo seja alterado quando o arquivo for movido para um determinado diretório. O mais parecido é o bit pegajoso, mas parece que você indicou que a propriedade do grupo não é suficiente, a propriedade real do usuário tem que mudar.

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

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

A ACL pode ajudar você a obter um controle de granularidade mais refinado sobre quem tem permissão para fazer o quê, não alterará automaticamente a propriedade real do arquivo para você. Acho que você precisa ter uma visão mais elevada e avaliar / redesenhar sua solução com base nisso.

    

Answer 5

Você pode usar inotify-tools e escrever um script simples como abaixo. O Inotify ficará de olho no diretório web e fará algo sempre que um evento como dir creation ocorrer dentro do diretório web. Existem muitos eventos existentes. Você pode pesquisar no Google ou pode procurar neste site

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