Tenho dificuldade em encontrar informações sobre o que realmente significam as permissões para dispositivos de bloco. Para dispositivos de bloco, o que significa permissão de leitura? Isso significa que não posso fazer coisas como hexdump? E quanto à permissão de gravação? Ou executar?
Além disso, e se você tiver permissão de montagem no dispositivo, dando ao usuário permissão sudo para montar apenas esse dispositivo específico, mas não permissões r,w ou x no dispositivo. O que acontecerá então?
Responder1
Para os casos simples (quando você acessa o dispositivo como um arquivo), é como @Jasen escreveu:
- A permissão de leitura permite a leitura do dispositivo (despejo, execução
fsckem modo somente leitura, etc.) - A permissão de gravação permite gravar no dispositivo (substituir por uma imagem, etc.)
- Ambas as permissões são necessárias para executar
fsck,tune2fsetc., que precisam ser lidasemodificar o sistema de arquivos. - A permissão de execução é ignorada. Se você tentar executar um arquivo de dispositivo, receberá 'Permissão negada' mesmo que o dispositivo de bloco contenha código executável válido.
Se você é root, geralmente obtém o CAP_DAC_READ_SEARCHeCAP_DAC_OVERRIDE capacidades, o que significa que os sinalizadores de permissão são completamente ignorados.
Paraioctlsé mais complicado:
Para executar um ioctl, você precisa ser capaz deabriro arquivo, o que significa que pelo menos você precisa de permissão de leitura ou gravação.
Todo o resto depende do driver. Alguns drivers de dispositivo verificam apenas recursos como CAP_SYS_RAWIOou CAP_SYS_ADMIN, alguns usam a permissão de leitura para ioctls "inofensivos", que fornecem apenas informações e a permissão de leitura + gravação para outros ioctls. Um driver de dispositivo pode usar a permissão de execução para uma verificação de permissão ioctl, mas não conheço nenhum driver que faça isso.
Paramontaré mais fácil:
O mountsyscall verifica apenas duas coisas:
- Você precisa ser capaz dealcançaro arquivo do dispositivo. Isso significa que todos os diretórios no caminho para o arquivo do dispositivo precisam ter pelo menos o bit de permissão de execução definido (ou você precisa ter a
CAP_DAC_READ_SEARCHcapacidade). - Você precisa ter a
CAP_SYS_ADMINcapacidade (que normalmente você obtém quando é root)
Os bits de permissão no próprio arquivo do dispositivo são completamente ignorados para montagem e não têm nenhuma influência no acesso ao sistema de arquivos montado.
Usandosudoexecuta o programa executado como root com todos os recursos disponíveis, o que significa que todas as verificações de permissão são ignoradas e como @Jasen escreveu em um comentário, /bin/mountgeralmente é setuid-root, o que faz com que ele sempre obtenha todos os recursos disponíveis, portanto, os bits de permissão não têm influência ativado mountna maioria das distribuições Linuxe outros sistemas operacionais unixoid.
EDITAR:as partes sobre capacidades são específicas do Linux. Outros sistemas operacionais unixoid como BSD ou OSX não separam as habilidades especiais do root em capacidades, então quando as capacidades são mencionadas, você simplesmente precisa ser root. Com base nas páginas de manual disponíveis, as verificações mountsão semelhantes às verificações específicas do Linux que descrevi. Não parece haver um sistema operacional que verifique os bits de permissão durante a montagem.
Responder2
read permite leitura (por exemplo, hexdump) write permite escrever (por exemplo, escrever uma imagem no dispositivo) em combinação, isso significa que você pode usar uma ferramenta como "hexedit" para visualizar e modificar o conteúdo.
Não sei o que x permite (possivelmente permite ioctl?)
como as permissões são, brwx______isso significa que apenas o proprietário (normalmente root) pode fazer essas coisas.