Estou procurando uma lista que especifique a permissão de arquivo convencional de todos os diferentes tipos de arquivos antes que o umask seja aplicado.
Eu li em man 1p touch que o padrão para um arquivo normal é:
S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH
Eu também vou em um membro e suponho que o padrão para um diretório e um link simbólico é:
S_IRWXU | S_IRWXG | S_IRWXO
No entanto, não consigo encontrar nas páginas man stat.h ou mknod.h / mknod quais são as permissões padrão de Sockets, FIFOs, Block devices e Char devices. Eles são iguais aos arquivos regulares? Ou perdi uma página de manual que explica isso?
Você parece ter entendido muito bem;
é discutido um pouco mais aqui .
O único ponto que você pode ter perdido é que você encontrou a declaração
na página man de touch(1) e não creat(2) ,
porque (com a possível exceção de links simbólicos),
não há padrões no nível do sistema -
cada programa tem seu próprio padrão individual.
Acontece que a maioria dos programas (se não todos) segue as mesmas regras.
As permissões para arquivos (sujeitas a umask ) estão definidas no open chamar quando o arquivo é criado pela primeira vez. Em fopen , as permissões são definidas como 0666, mas isso lida com o fluxo I / O. Dependendo do aplicativo que cria os arquivos, eles podem usar o nível aberto de abertura / leitura / gravação - ou não.
Dispositivos especiais seriam criados usando mknod , novamente com o aplicativo especificando as permissões iniciais. Por exemplo, os comandos mkfifo usados com o Linux e OSX tem uma opção para definir a permissão. Da mesma forma, o comando [mknod][6] tem uma opção para definir a permissão. Os manuais para estes não especificam as permissões iniciais.
Curiosamente, a descrição POSIX de mkfifo não indica nenhum conjunto particular de permissões (além de documentar uma opção para defini-los).
Considerando a falta de especificidade, existe a possibilidade de que algumas implementações desses comandos não usem 0666 para permissões, mas se essa implementação hipotética é mais flexível ou mais rigorosa não é clara. Se você examinar o conteúdo de /dev , geralmente não encontrará dispositivos especiais que sejam graváveis pelo mundo. Isso pode ser imposto por uma determinada implementação. Por exemplo, se um dispositivo especial tiver permissão executar , isso pode não ser uma coisa boa , já que seu conteúdo (normalmente) não é como um arquivo normal, e coisas inesperadas podem acontecer se foi "executado".
Sem documentação, qualquer resposta sobre as permissões convencionais teria que ficar restrita a observações de implementações específicas. As permissões 0666 são amplamente usadas para arquivos não executáveis, mas não há garantia de que isso seja uma verdade universal.
As permissões de um link simbólico , por outro lado, são decididamente específicas do sistema. A symlink(7) página de manual do Linux diz que eles são sempre 0777:
On Linux, the permissions of a symbolic link are not used in any operations; the permissions are always 0777 (read, write, and execute for all user categories), and can't be changed.
Em outros sistemas, pode ser possível, por exemplo, os BSDs como FreeBSD e OSX documenta uma opção -h que pode ser usada para modificar as permissões, embora a documentação da chamada symlink(2) correspondente ( FreeBSD , OSX não menciona as permissões iniciais.
Leitura adicional:
Na maioria dos sistemas, o privilégio padrão dos arquivos de disco antes que o umask seja aplicado é o mesmo que os arquivos regulares. (0666)
Tags permissions chmod umask