Por que os arquivos no meu diretório pessoal estão sendo criados como graváveis ​​no mundo, apesar de umask mais restritiva?


10

Percebi que as permissões para novos arquivos e diretórios se comportam um pouco estranhamente. Primeiro de tudo, umask parece retornar a resposta certa:

$ umask
0002

Isso significa acesso total para meu usuário e meu grupo, sem acesso de gravação para o resto do mundo, sem suid. Mas se eu criar um arquivo no meu $ HOME, é assim:

$ ls -l testfile 
-rw-rw-rw- 1 robe robe 0 mar 16 12:58 testfile

ou seja, dando acesso de gravação a todos. O mesmo acontece com os diretórios:

$ ls -ld testdir
drwxrwxrwx 2 robe robe 6 mar 16 13:00 testdir

Eu acho que é o mesmo que ter umask 0000, não 0002. Eu procurei em todo / etc por alguma instância de umask que altera o padrão 0002 ou 0022, mas não encontrei nenhum. Esta é uma instalação padrão do CentOS 5.5. Alguma dica de por que isso está acontecendo?


3
Em que tipo de sistema de arquivos está o diretório inicial?
mattdm

4
E como você está criando testfilee testdir?
mattdm

3
@mattdm, você estava certo em insistir: é XFS. Esqueci que temos volumes separados para / home, / var e vários outros. Embora eu use o XFS frequentemente e não tenha visto esse comportamento. Como isso pode ser relacionado?
rsuarez

2
O acl pode substituir umask localmente. É possível que seus diretórios estejam sendo montados com o acl?
Faheem Mitha 17/03/11

3
Hmm, aparentemente o xfs sempre tem o ACL ativado. portanto, pode não aparecer no seu / etc / fstab. Tente executar o getfacl em suas partições / diretórios.
Faheem Mitha 17/03/11

Respostas:


3

Não sei se é adequado responder à minha própria pergunta. Os editores, por favor, aconselhem-no se este não for o caso. Desde já, obrigado.

Acho que resolvi esse mistério: o problema era a falta de uma ACL padrão nos volumes XFS. Aqui está a entrada da ACL para / srv / backups, um dos diretórios afetados:

# file: srv/backups
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Sempre que eu fazia um "teste de mkdir" ou "touch testfile", as permissões eram 777. Então, eu fazia o seguinte:

setfacl -m d:u::rwx /srv/backups

Deixando a ACL assim:

# file: srv/backups
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

Anteriormente (supostamente) não havia ACL, mas agora existe. Eu posso ver o sinal "+" anexado às permissões quando faço um "ls -l". E, magicamente, agora "mkdir test" e "touch testfile" funcionam com as permissões esperadas:

# ls -l testfile 
-rw-r--r-- 1 root root 0 Dec 20 10:00 testfile
# ls -ld testdir
drwxr-xr-x+ 2 root root 6 Dec 20 10:00 testdir

Não sei por que isso acontece. Eu acho que o XFS não gosta de não ter uma ACL padrão e se comporta de maneira estranha quando isso acontece. Além disso, eu já vi isso acontecer apenas no CentOS, não no Debian / Ubuntu. Talvez esteja relacionado à versão XFS no kernel, ou algo assim. Nenhuma idéia.

Enfim, isso resolve o caso para mim. Muito obrigado por todas as sugestões :-)


Responder a sua própria pergunta é perfeitamente aceitável .
Keith Thompson

0

A chamada creat pode especificar explicitamente permissões que têm precedência sobre umask.

Você não respondeu como está criando testfile,testdir.

Crie o arquivo usando touch testfile, em seguida, liste e publique as permissões


Desculpe o atraso. Eu testei usando "touch testfile" e também "mkdir testdir", com resultados semelhantes. umask parece estar definida como "0000", porque elas são criadas com permissões 777.
rsuarez

0

Tente a getfacl .no diretório em que você está criando seu arquivo de teste, para ver se há uma ACL padrão que afeta as permissões.


1
Não, nenhuma ACL padrão. Parece estar relacionado ao XFS de alguma forma, porque isso acontece apenas em volumes XFS. Mas obrigada mesmo assim.
rsuarez

-1

Basta procurar a variável USERGROUPS_ENAB em /etc/login.defs

Eles comentam para desativá-lo # USERGROUPS_ENAB yes

Se você também quiser alterar o umask do usuário atual, primeiro siga o procedimento anterior e faça o seguinte.

exemplo para 027

eco "umask 027" >> ~ / .bashrc && pkill -KILL -u your_username_here

eco "umask 027" >> ~ / .bashrc Este comando definirá um valor padrão umask para o seu perfil

isso forçará você a sair

após o login novamente

basta executar o comando umask novamente e ver se funciona para você

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.