Acredito que o sistema de arquivos FAT32 não suporta permissões de arquivo, no entanto, quando o faço ls -lem uma partição FAT32, ls -lmostra que os arquivos têm permissões:
-rw-r--r-- 1 john john 11 Mar 20 15:43 file1.txt
-rw-r--r-- 1 john john 5 Mar 20 15:49 file2.txt
Por que ls -lexibir as permissões de arquivos?
Respostas:
O sistema de arquivos armazenado no disco não armazena permissões de arquivo, mas o driver do sistema de arquivos deve fornecê-las ao sistema operacional, pois são parte integrante do conceito de sistema de arquivos Unix e as interfaces de chamada do sistema não têm como apresentar que as permissões são ausência de.
Considere também o que aconteceria se um arquivo não tivesse nenhum bit de permissão? Seria o mesmo que 0777, ou seja, acesso a todos; ou o mesmo que 0000, ou seja, sem acesso a ninguém? Mas essas duas são permissões de arquivo, então por que não mostrá-las? Ou faça algo mais útil e tenha uma maneira de definir algumas permissões sensatas.
Portanto, o driver falsifica algumas permissões, mesmas para todos os arquivos. As permissões, juntamente com o proprietário e o grupo dos arquivos, são configuráveis no momento da montagem. Eles estão descritos em "Opções de montagem para gordura" na página do manual mount (8) :
Opções de montagem para fat
(Nota: fat não é um sistema de arquivos separado, mas uma parte comum dos sistemas de arquivos msdos, umsdos e vfat.)
uid=valueegid=value
Defina o proprietário e o grupo de todos os arquivos. (Padrão: o UID e o GID do processo atual.)
umask=value
Defina a umask (a máscara de bits das permissões que não estão presentes). O padrão é a umask do processo atual. O valor é dado em octal.
dmask=value
Defina o umask aplicado apenas aos diretórios. O padrão é a umask do processo atual. O valor é dado em octal.
fmask=value
Defina o umask aplicado apenas aos arquivos regulares. O padrão é a umask do processo atual. O valor é dado em octal.
Observe que as permissões são apresentadas como máscaras; portanto, as permissões finais são a negação da máscara. fmask=0133resultaria em todos os arquivos com permissões 0644ou rw-r--r--.
Além disso, os padrões são herdados da chamada de processo mount(), portanto, se você chamar mountda linha de comando, os shell umaskserão aplicados.
umaskopção de montagem, para a qual o valor padrão é umask do mountprocesso (consulte a página de manual vinculada nesta resposta).
chmod ugo-wem um arquivo ativará o atributo somente leitura. Usar a fmask=0133opção como no seu exemplo não resultará em todos os arquivos com a permissão 0644. O que o FAT absolutamente não armazena é um uid e um gid para cada arquivo. Por favor, esclareça; a resposta como está é altamente enganadora.
Mas os arquivos têm permissões. O usuário john tem acesso RW, enquanto algum usuário aleatório possui apenas acesso de leitura. Essas permissões não vieram do próprio sistema de arquivos, mas das opções de montagem (-o uid / gid / umask), que não as tornam menos reais.
Você poderia ter várias partições vfat montadas com opções diferentes e usar ls para determinar quais eram essas opções. Você pode até usar o mount --bind para que um único diretório contenha arquivos de diferentes partições vfat, e o ls mostrará corretamente quais permissões foram especificadas para cada arquivo.
lsnão conhece o FAT32, apenas conhece a interface do sistema de arquivos virtual (VFS) exposta pelo kernel com chamadas de sistema POSIX open/ readdir/ stat.
O Linux não suporta o conceito de arquivos que não possuem bits de permissão usuário / grupo / outros, struct statsimplesmente contém um mode_t st_mode;membro (e membros uid, gid) que o kernel deve preencher ao ls -lfazer stat(2)chamadas do sistema.
Não há código especial que signifique "não disponível" ou "não aplicável" para nenhum desses campos; portanto, o driver vfat do kernel deve criar algo. O FAT16 / FAT32 possui um sinalizador somente leitura, mas, caso contrário, o proprietário / grupo vem das opções de montagem, e o umask também.