umask, mistérios e lendas

Palavras-Chave: Linux

Pessoal, primeiramente peço perdão a Alah por não ter postado neste blog por muito tempo... Continuarei neste rítmo uma vez que a correria tá braba!!

Eu tava me preparando pra escrever isso há dias mas não sobrava tempo. O que ocorre é que existe um recurso nem tão freqüentemente utilizado em ambientes UNIX, chamado de umask. O umask nada mais é do que uma "mascara" utilizada para definir as permissões padrões de novos arquivos e diretórios. Mais ao fim eu explico o "espírito" da umask, mas por enquanto vamos contar um pouco da aventura.


No tempo que eu era um "gurizote", nem tão barrigudo quanto sou hoje, eu aprendi, com repetidores de lendas, que a tal da umask era um "número", que subtraído de 777 nos dava a permissão que ia ser utilizada para novos diretórios, e que subtraído de 666 nos dava a permissão que ia ser utilizada para novos arquivos.

Quando eu comprei alguns livros para estudo, como o "Certificação Linux", do Uirá Ribeiro(recomendo, propaganda grátis hehehe), que me confirmavam o que eu havia lido(e nunca havia testado tão a fundo). Nos exemplos que sempre são passados por estes repetidores de informação(me incluo neles) temos sempre a típica umask que coincide com o cálculo errôneo, e que é a umask padrão de todos os sistemas: a umask 022.

Na minha vida prática, só precisei utilizar outra umask, DURANTE MUITOS ANOS, quando trabalhei com SVN sobre SSH. O que acontecia neste caso é que os novos arquivos do repositório SVN precisavam ter permissão de escrita para o grupo também, senão nenhum outro usuário alteraria o conteúdo criado por outro no repositório. Para isso ser possível, alterei de 022 para 002 a umask do sistema. Com esta umask, também havia a dita coincidência com o "lendário cálculo"(os números '0' e '2' são 'mágicos' em certas operações matemáticas binárias).

Esses dias estava com uma turma de alunos, aonde, como muito ocorre com todo mundo, fui um repetidor de informações no que se refere à umask. Normalmente eu não falava dela em aulas, pois para mim aquilo parecia inútil até o recente episódio do SVN+SSH. Resolvi passar ela para o pessoal, que foi fazer uns testes e achou alguns casos que não batiam. Desde então, fui pesquisar e achei 50% das informações na internet falando da "lenda da subtração de umask". as outras 50% eram outras informações semelhantes que não batiam também. As man pages umask(2), open(2), creat(2) e mkdir(2) também não foram muito úteis na tarefa, pois não pareciam estar escritas de maneira clara.

Então, lá fui eu ler os fontes do kernel. No diretório 'fs' dos fontes nós encontramos a informação. Lendo os arquivos Procurando pelas funções das system calls(sys_mkdir, sys_open e sys_creat), achei o arquivo namei.c, aonde haviam 2 repetições de um trexo bem interessante do código:
if (!IS_POSIXACL(nd.dentry->d_inode))
mode &= ~current->fs->umask;

Então percebi que as man pages, apesar de pouco claras, estavam 100% certas. O cálculo da permissão se dá por uma operação AND(binária, bit a bit) entre o modo passado. Claro que para tudo há um porém.

Concluí em alguns testes que a umask só é aplicada quando os valores default são passados para as system calls que utilizam a umask(as system calls creat, open, mknod e mkdir, que criam nodos no sistema de arquivos, e os valores default são 777 para diretório e 666 para arquivo). Fica a promessa para mais adiante eu investigar aonde essa condição de verificação da umask é aplicada e mandar para todos a informação completa.

Como falei lá em cima, entendi o "espírito" da umask, que é basicamente você definir os bits que você quer que NÃO sejam ativados para arquivos e diretórios novos. Simples assim.

Para quem não é acostumado com matemática binária, segue a referência para entender as operações envolvidas na umask(AND e NOT):

• http://en.wikipedia.org/wiki/Binary_and
• http://en.wikipedia.org/wiki/Bitwise_operation#NOT

Lembro a todos ainda que isso tudo depende muito de como os programas fazem a chamada, uma vez que se o programa requisitado passar na system call o modo diferente do padrão, a umask não será aplicada. Um caso aonde isso ocorre é quando passamos ao mkdir a flag '-m' indicando um modo diferente.

Fico devendo ainda uma explicação melhor sobre essa excessão, pois ainda não localizei aonde esse tratamento é feito. Estou analisando a libc também para encontrar o "caminho completo". Se alguém tiver uma sugestão ou resposta antes, comenta aí!!

OBS: Saindo em breve do forno um artigo sobre uso de NAT no user-space através das libs do netfilter. Esperem e verão!

Classificação do conteúdo: SÉRIO
Sobre Bruno Moreira Guedes:
Curriculum Vitae
Site Pessoal