Forçar permissões arquivos/diretórios em acesso LOCAL
Ivo Santos Cavalcante Carneiro
Após muito tempo sem postar nada, estou de volta e precisando de uma ajuda.
Preciso criar uma árvore de diretórios em que alguns usuários podem
acessar livremente - entenda-se copiar, alterar e deletar arquivos,
inclusive uns dos outros. Infelizmente, não consegui colocar as coisas
desse modo. Já setei o SGID no diretórios, mas não houve jeito. Segue
exemplo abaixo:
dirPai - dono: root, grupo: data-ladm, permissões: drwxrwsr-x
dirPai/dirFilho: dono: root, grupo: data-ladm, permissões: drwxrwsr-x
Minha intenção era que todo arquivo/diretório criado em dirPai e ou
dirFilho tivessem o grupo setado para 'data-ladm', com permissões de
leitura e escrita. Dessa forma, conseguiria o tipo de controle que
preciso. Descobri, pra meu desgosto, que comandos como 'mv' e 'cp'
quebram a regra. Faz até sentido, visto que, se um usuário é dono do
arquivo, pode alterar as permissões e grupos sem problemas. O 'touch',
obviamente, funciona.
Fica então a pergunta: alguém sabe como forçar esses grupos/permissões?
P.S. 1: já pesquisei no Google, antes que perguntem... :-)
P.S. 2: já li os manuais, pelo menos os que achei pertinentes.
P.S. 3: já pensei em soluções drásticas, como montar um arquivo com
sistema de arquivos FAT32 e setar permissões no mount, mas quero tentar
fazer as coisas de uma forma mais limpa.
Abraços,
Ivo Cavalcante
--
To UNSUBSCRIBE, email to debian-user-por...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paulo Ricardo Bruck
escreveu:
> Olá amigos.
olá 8)
>
> Após muito tempo sem postar nada, estou de volta e precisando de uma ajuda.
>
ok vamos lá
> Preciso criar uma árvore de diretórios em que alguns usuários podem
> acessar livremente - entenda-se copiar, alterar e deletar arquivos,
> inclusive uns dos outros. Infelizmente, não consegui colocar as coisas
> desse modo. Já setei o SGID no diretórios, mas não houve jeito. Segue
> exemplo abaixo:
>
> dirPai - dono: root, grupo: data-ladm, permissões: drwxrwsr-x
> dirPai/dirFilho: dono: root, grupo: data-ladm, permissões: drwxrwsr-x
>
> Minha intenção era que todo arquivo/diretório criado em dirPai e ou
> dirFilho tivessem o grupo setado para 'data-ladm', com permissões de
> leitura e escrita. Dessa forma, conseguiria o tipo de controle que
> preciso. Descobri, pra meu desgosto, que comandos como 'mv' e 'cp'
> quebram a regra. Faz até sentido, visto que, se um usuário é dono do
> arquivo, pode alterar as permissões e grupos sem problemas. O 'touch',
> obviamente, funciona.
>
> Fica então a pergunta: alguém sabe como forçar esses grupos/permissões?
>
sim man bash procurando por umask:
umask [-p] [-S] [mode]
The user file-creation mask is set to mode. If mode
begins with a digit, it is interpreted as an octal number; otherwise
it is interpreted as a symbolic mode mask similar to that accepted by
chmod(1). If mode is omitted, the current value of the
mask is printed. The -S option causes the mask to be printed in
symbolic form; the default output is an octal number. If the -p option
is supplied, and mode is omitted, the output is in a form that may
be reused as input. The return status is 0 if the mode was
successfully changed or if no mode argument was supplied, and false
otherwise.
ou do guia foca:
http://focalinux.cipsga.org.br/guia/inic_interm/ch-perm.htm#s-perm-umask
[]s
> P.S. 1: já pesquisei no Google, antes que perguntem... :-)
> P.S. 2: já li os manuais, pelo menos os que achei pertinentes.
> P.S. 3: já pensei em soluções drásticas, como montar um arquivo com
> sistema de arquivos FAT32 e setar permissões no mount, mas quero tentar
> fazer as coisas de uma forma mais limpa.
>
>
>
> Abraços,
> Ivo Cavalcante
>
>
--
Paulo Ricardo Bruck - consultor
Contato Global Solutions
tel 011 5031-4932 fone/fax 011 5034-1732 cel 011 9235-4327
Ivo Santos Cavalcante Carneiro
Vamos mesmo, estou agora mais curioso que nunca!!!
> sim man bash procurando por umask:
> umask [-p] [-S] [mode]
> The user file-creation mask is set to mode. If mode
> begins with a digit, it is interpreted as an octal number; otherwise
> it is interpreted as a symbolic mode mask similar to that accepted by
Do 'man umask' também:
The umask is used by open(2) to set initial file permissions on a
newly-created file. Specifically, permissions in the umask are turned
off from the mode argument to open(2) (so, for example, the common
umask default value of 022 results in new files being created with per-
missions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the
mode is specified as 0666).
Resumindo: o 'umask' seta as permissões para um arquivo novo,
recém-criado. Não é o caso. Arquivos novos, seguindo as configurações de
diretório que passei no email anterior, funcionam como eu quero sem
precisar do umask. O problema está no comando 'mv', por exemplo. Se crio
um arquivo no meu home e movo para o diretório configurado, ele vai com
as permissões, dono e grupo que foi originalmente criado, sem preservar
as configurações que eu queria. Entendeu?
Não sei ao certo se, após criar os arquivos no novo diretório, o mv seta
as permissões, dono e grupo originais - provável, já que, se criei o
arquivo, posso alterar seus parâmetros - ou se já vêm 'embutido' no
processo de move-los, mas o fato é que quebra o esquema.
É isso. Ainda no aguardo de novas sugestões...
Marcos Vinicius Lazarini
O esquema é quebrado, mas devido ao chmod g+s, vc faz parte do mesmo grupo
do arquivo e tbm pode mudar a permissão ao seu gosto, não?
É a unica saida (prática) que vejo...
Outra saida que fiz: criei pra cada usuário um grupo pessoal e unico, mudei
seu umask pra 002 (ou 007, nao lembro). Depois, dei um 'chown -R user.user
~user; chmod -R g+w ~user' (assim, todos tem permissão de escrita pro grupo,
mas como o grupo é formado por ele mesmo, nao tem problema).
Depois vc vai criando os demais grupos que precisar, adiciona as pessoas que
farão parte, e de o 'chmos g+s <pasta>' pra sempre mudar o grupo dos
arquivos criados/copiados/movidos pra dentro.
--
Marcos
Ivo Santos Cavalcante Carneiro
> O esquema é quebrado, mas devido ao chmod g+s, vc faz parte do mesmo
> grupo do arquivo e tbm pode mudar a permissão ao seu gosto, não?
Infelizmente não, Marcos. É aí que reside todo o problema: mesmo com
SGID setado no diretório pai, os arquivos e diretórios criados nele vêm
com o grupo original quando movidos com o 'mv'. No caso de arquivos
dentro do diretório pai, menos mal. A permissão de escrita pro grupo, no
diretório, permite que eu o apague. Mas e os subdiretórios que pertençam
a grupos diferentes do diretório pai, devido ao 'mv'? Os outros usuários
do grupo podem não ter permissão nenhuma nele!
> Outra saida que fiz: criei pra cada usuário um grupo pessoal e unico,
> mudei seu umask pra 002 (ou 007, nao lembro). Depois, dei um 'chown -R
> user.user ~user; chmod -R g+w ~user' (assim, todos tem permissão de
> escrita pro grupo, mas como o grupo é formado por ele mesmo, nao tem
> problema).
> Depois vc vai criando os demais grupos que precisar, adiciona as pessoas
> que farão parte, e de o 'chmos g+s <pasta>' pra sempre mudar o grupo dos
> arquivos criados/copiados/movidos pra dentro.
Não sei se entendi bem essa parte, mas o que eu quero evitar é
justamente isso, precisar executar sempre um 'chown', 'chmod' nos
diretórios pra manter as permissões em dia. Muito trabalhoso.
Ah, só uma correção: contrariando o que eu disse antes, o 'cp' não
quebra o esquema, a não ser que seja usado o parâmetro '-p' - preserva
os atributos originais.
Muito estranho isso, vou verificar com mais calma, mas acho que nos
Windows NT's e cia - 2000, XP, etc. -, com sistema de arquivos NTFS,
você faz isso fácil fácil... Vou verificar com calma.
Sugestões?
Abraços,
Ivo Cavalcante
Marcos Vinicius Lazarini
>
>> O esquema é quebrado, mas devido ao chmod g+s, vc faz parte do mesmo
>> grupo do arquivo e tbm pode mudar a permissão ao seu gosto, não?
>
>
> Infelizmente não, Marcos. É aí que reside todo o problema: mesmo com
> SGID setado no diretório pai, os arquivos e diretórios criados nele vêm
> com o grupo original quando movidos com o 'mv'. No caso de arquivos
> dentro do diretório pai, menos mal. A permissão de escrita pro grupo, no
> diretório, permite que eu o apague. Mas e os subdiretórios que pertençam
> a grupos diferentes do diretório pai, devido ao 'mv'? Os outros usuários
> do grupo podem não ter permissão nenhuma nele!
Bom, isso é verdade... acabei de constatar isso - o 'mv' mantem
exatamente os ownerships, e ai detona o esquema...
>> Outra saida que fiz: criei pra cada usuário um grupo pessoal e unico,
>> mudei seu umask pra 002 (ou 007, nao lembro). Depois, dei um 'chown -R
>> user.user ~user; chmod -R g+w ~user' (assim, todos tem permissão de
>> escrita pro grupo, mas como o grupo é formado por ele mesmo, nao tem
>> problema).
>> Depois vc vai criando os demais grupos que precisar, adiciona as
>> pessoas que farão parte, e de o 'chmos g+s <pasta>' pra sempre mudar o
>> grupo dos arquivos criados/copiados/movidos pra dentro.
>
> Não sei se entendi bem essa parte, mas o que eu quero evitar é
> justamente isso, precisar executar sempre um 'chown', 'chmod' nos
> diretórios pra manter as permissões em dia. Muito trabalhoso.
Pois eh, vc nao entendeu bem. Vc só vai fazer isso uma vez.
Mas mesmo assim vai dar problema com o 'mv' do mesmo jeito.
> Ah, só uma correção: contrariando o que eu disse antes, o 'cp' não
> quebra o esquema, a não ser que seja usado o parâmetro '-p' - preserva
> os atributos originais.
Eu acho que a solução é vc não ensinar o 'mv' aos seus usuários! :-)
Ou então substitua o 'mv' por um alias/script que copia e depois remove
o original; ou ainda faça as coisas de um jeito que o usuário não
precise fazer 'mv' dos arquivos (homedir pequeno, área comum grande;
deixe pré-setado coisas nas áreas publicas, etc)
> Muito estranho isso, vou verificar com mais calma, mas acho que nos
> Windows NT's e cia - 2000, XP, etc. -, com sistema de arquivos NTFS,
> você faz isso fácil fácil... Vou verificar com calma.
é, isso não sei nao. Já tive problemas com essas permissoes tbm - se o
cara move tbm dá dor de cabeça.
--
Marcos
Tiago Saboga
Se colocar um script no cron, não dá mais trabalho nenhum... Que tal?
>
> Pois eh, vc nao entendeu bem. Vc só vai fazer isso uma vez.
> Mas mesmo assim vai dar problema com o 'mv' do mesmo jeito.
>
> > Ah, só uma correção: contrariando o que eu disse antes, o 'cp' não
> > quebra o esquema, a não ser que seja usado o parâmetro '-p' - preserva
> > os atributos originais.
>
> Eu acho que a solução é vc não ensinar o 'mv' aos seus usuários! :-)
> Ou então substitua o 'mv' por um alias/script que copia e depois remove
> o original; ou ainda faça as coisas de um jeito que o usuário não
> precise fazer 'mv' dos arquivos (homedir pequeno, área comum grande;
> deixe pré-setado coisas nas áreas publicas, etc)
>
> > Muito estranho isso, vou verificar com mais calma, mas acho que nos
> > Windows NT's e cia - 2000, XP, etc. -, com sistema de arquivos NTFS,
> > você faz isso fácil fácil... Vou verificar com calma.
>
> é, isso não sei nao. Já tive problemas com essas permissoes tbm - se o
> cara move tbm dá dor de cabeça.
Não lembro bem, mas me parece que já li em algum lugar sobre um conceito
diferente de permissões, que seria originário de outro OS ou algo assim, e
para qual haveria (?) um patch para o kernel do linux. Ou uma história
parecida. Será que alguém sabe mais a respeito?
> --
> Marcos
[]s,
tiago.
Marcelo Beckmann
Já vi uma discussão sobre mv x [us]gid em outra ocasião, e é isso mesmo.
O mv passa por cima.
Sugeriria também um cron para esse caso.
---8<---
> Não lembro bem, mas me parece que já li em algum lugar sobre um conceito
> diferente de permissões, que seria originário de outro OS ou algo assim, e
> para qual haveria (?) um patch para o kernel do linux. Ou uma história
> parecida. Será que alguém sabe mais a respeito?
sim, é um patch relacionado a acl's
é útil quando se quer permissões variadas com vários usuários/grupos
tendo acesso, uns podendo escrever outros não e coisa e tal
mas nesse caso um cron resolveria (ou um mv script modificado) de forma
mais simples, creio eu.
Marcos Vinicius Lazarini
> Em Qua 13 Abr 2005 19:27, Marcos Vinicius Lazarini escreveu:
>
>>Ivo Santos Cavalcante Carneiro wrote:
>>
>>>Marcos Vinicius Lazarini wrote:
>>>
>>>>Outra saida que fiz: criei pra cada usuário um grupo pessoal e unico,
>>>>mudei seu umask pra 002 (ou 007, nao lembro). Depois, dei um 'chown -R
>>>>user.user ~user; chmod -R g+w ~user' (assim, todos tem permissão de
>>>>escrita pro grupo, mas como o grupo é formado por ele mesmo, nao tem
>>>>problema).
>>>>Depois vc vai criando os demais grupos que precisar, adiciona as
>>>>pessoas que farão parte, e de o 'chmos g+s <pasta>' pra sempre mudar o
>>>>grupo dos arquivos criados/copiados/movidos pra dentro.
>>>
>>>Não sei se entendi bem essa parte, mas o que eu quero evitar é
>>>justamente isso, precisar executar sempre um 'chown', 'chmod' nos
>>>diretórios pra manter as permissões em dia. Muito trabalhoso.
>
>
> Se colocar um script no cron, não dá mais trabalho nenhum... Que tal?
O problema é a 'latência' - de quanto em quanto tempo é razoável? muito
tempo faz vc esperar de bobeira, pouco tempo gasta mais CPU...
eu realmente nao considero uma boa solução.
Ivo Santos Cavalcante Carneiro
>> Se colocar um script no cron, não dá mais trabalho nenhum... Que tal?
>
>
> O problema é a 'latência' - de quanto em quanto tempo é razoável? muito
> tempo faz vc esperar de bobeira, pouco tempo gasta mais CPU...
> eu realmente nao considero uma boa solução.
Nem eu, Marcos. Não me conformo! Uma coisa aparentemente tão simples!
Tem uma outra solução, bem forçada, que citei no primeiro mail: criar um
arquivo com sistema de arquivos FAT32 e montar forçando as permissões
de grupo / usuário. Faço isso em uma partição FAT32 que tenho aqui,
funciona bem. Não sei quanto a desempenho, mas.....
Sugestões / comentários?
Abraços,
Ivo Cavalcante
Paulo Ricardo Bruck
escreveu:
> Marcos Vinicius Lazarini wrote:
> >> Se colocar um script no cron, não dá mais trabalho nenhum... Que tal?
> >
> >
> > O problema é a 'latência' - de quanto em quanto tempo é razoável? muito
> > tempo faz vc esperar de bobeira, pouco tempo gasta mais CPU...
> > eu realmente nao considero uma boa solução.
>
> Nem eu, Marcos. Não me conformo! Uma coisa aparentemente tão simples!
> Tem uma outra solução, bem forçada, que citei no primeiro mail: criar um
> arquivo com sistema de arquivos FAT32 e montar forçando as permissões
> de grupo / usuário. Faço isso em uma partição FAT32 que tenho aqui,
> funciona bem. Não sei quanto a desempenho, mas.....
>
> Sugestões / comentários?
ok vcs venceram..80)
vc pode usra as ACL do kernel para isto ( preferencialmente o kernel 2.6
que já tem suporte nativo). veja os pacotes:
aptitude show acl
Pacote : acl
Estado: não instalado
Versão : 2.2.29-1.0.1
Prioridade : opcional
Seção : utils
Mantenedor : Nathan Scott <nat...@debian.org>
Tamanho Descompactado : 127k
Depende de: libacl1, libattr1 (>= 2.4.4-1), libc6 (>= 2.3.2.ds1-4)
Descrição : Access control list utilities
This package contains the getfacl and setfacl utilities needed for
manipulating
access control lists.
e um excelente tutorial sobre acl ( heheheh do pessoal do fedora)
http://www.vanemery.com/Linux/ACL/linux-acl.html
se alguem tiver um tutorial em portugues melhor , por favor repassem a
lista 8)
ats