Como funcionam as permissões / atributos de arquivo? Nível de kernel, nível de FS ou ambos?

Uma pergunta que me ocorreu anteriormente: as permissões / atributos de arquivos são dependentes do sistema operacional (e, portanto, do kernel) ou dependem do sistema de arquivos? Parece-me que a segunda alternativa é a mais lógica, mas nunca ouvi falar de reiserfspermissões de arquivo, por exemplo: apenas "Permissões de arquivo Unix". Por outro lado, para citar um artigo da Wikipedia :

À medida que novas versões do Windows foram lançadas, a Microsoft adicionou ao inventário de atributos disponíveis no sistema de arquivos NTFS

o que parece sugerir que os atributos de arquivo do Windows estão de alguma forma ligados ao sistema de arquivos.

Alguém por favor pode me esclarecer?

Tanto o kernel quanto o sistema de arquivos desempenham um papel. As permissões são armazenadas no sistema de arquivos, portanto, é necessário que haja um local para armazenar as informações no formato do sistema de arquivos. As permissões são impostas e comunicadas aos aplicativos pelo kernel; portanto, o kernel deve implementar regras para determinar o que significam as informações armazenadas no sistema de arquivos.

“Permissões de arquivo Unix” refere-se a um sistema de permissão tradicional que envolve três ações (leitura, gravação, execução) controladas por três tipos de função (usuário, grupo, outro). O trabalho do sistema de arquivos é armazenar 3 × 3 = 9 bits de informação. O trabalho do kernel é interpretar esses bits como permissões; em particular, quando um processo tenta uma operação em um arquivo, o kernel deve determinar, considerando o usuário e os grupos em que o processo está sendo executado, os bits de permissão do arquivo e a operação solicitada, se deseja permitir a operação. (“Permissões de arquivo Unix” também geralmente inclui bits setuid e setgid , que não são estritamente permissões.)

Os sistemas unix modernos podem suportar outras formas de permissões. A maioria dos sistemas unix modernos (Solaris, Linux, * BSD) suporta listas de controle de acesso que permitem atribuir permissões de leitura / gravação / execução para mais de um usuário e mais de um grupo para cada arquivo. O sistema de arquivos deve ter espaço para armazenar essas informações extras e o kernel deve incluir código para procurar e usar essas informações. Ext2, reiserfs, btrfs, zfs e a maioria dos outros formatos modernos de sistema de arquivos unix definem um local para armazenar essas ACLs. O Mac OS X suporta um conjunto diferente de ACL, que inclui permissões não tradicionais, como "anexar" e "criar subdiretório"; o formato do sistema de arquivos HFS + os suporta. Se você montar um volume HFS + no Linux, essas ACLs não serão aplicadas, pois o kernel do Linux não as suporta.

Por outro lado, existem sistemas operacionais e sistemas de arquivos que não oferecem suporte ao controle de acesso. Por exemplo, o FAT e as variantes foram projetados para sistemas operacionais de usuário único e mídia removível e suas permissões são limitadas a leitura / leitura / gravação e oculto / visível. Essas são as permissões impostas pelo DOS . Se você montar um sistema de arquivos ext2 no DOS, ele não aplicará as permissões ext2. Por outro lado, se você acessar um sistema de arquivos FAT no Linux, todos os arquivos terão as mesmas permissões.

Versões sucessivas do Windows adicionaram suporte para mais tipos de permissão. O sistema de arquivos NTFS foi estendido para armazenar essas permissões extras. Se você acessar um sistema de arquivos com as permissões mais recentes em um sistema operacional mais antigo, o SO não saberá sobre essas permissões mais recentes e não as aplicará. Por outro lado, se você acessar um sistema de arquivos mais antigo com um sistema operacional mais novo, ele não terá as novas permissões e caberá ao sistema operacional fornecer fallbacks sensatos.

A fim de usuários certos direitos ambos o kernel e o sistema de arquivos deve apoiá-los. Se o sistema de arquivos nem mesmo suportar os direitos de acesso mais básicos, o código do sistema de arquivos precisará falsificá-los (por exemplo, com a opção mount umaskpara vfat).

Meu entendimento é que o kernel implementa inodes no VFS. inodes contêm informações de permissão (UNIX e ACL) junto com outros metadados e o sistema de arquivos pode estender o inode para adicionar recursos. Se você estiver interessado, leia sobre Linux VFS - coisas complicadas se você não é um programador de sistemas.

Como regra geral, a permissão e os atributos dos arquivos são armazenados no sistema de arquivos [a maneira exata depende do sistema de arquivos em questão (ext3 / 4, riser, NTFS etc ...)], mas são usados pelo kernel, normalmente para impor algo.

Por exemplo, o kernel no * nix como sistema é "a coisa" que conhece o significado do UID associado a um arquivo / diretório. Um UID de arquivo é simplesmente um número armazenado juntamente com um arquivo certan pelo sistema de arquivos, mas a "tradução" desse número para um determinado usuário (e os direitos correspondentes para fazer algo ou não) é feita pelo kernel.