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

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?

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 :-)

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

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.

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ê