mount options para bindmount

Question

Devido a alguns requisitos complexos, tive que colocar as duas linhas a seguir em /etc/fstab :

/dev/xvdg1        /srv/storage  ext4  $OPTIONS1      0 2
/srv/storage/dir  /var/opt/dir  none  bind,$OPTIONS2 0 0

Agora, minha pergunta é: Tenho que listar novamente todas as opções de montagem $ OPTIONS1 em $ OPTIONS2, ou a segunda linha (a linha de ligação) herdará as opções de $ OPTIONS1?

FYI, aqui estão as opções reais usadas em $ OPTIONS1:

rw,auto,async,noatime,nodiratime,barrier=0,delalloc

ETA : na verdade, uso UUID=... em vez de /dev/xvdg1 , mas isso não vem ao caso.

    

Answer 1

A resposta curta é "talvez", porque depende de qual opção você está passando e por que ela é aplicada. Se as opções que você está passando forem estritamente flags de superblock, não será necessário relistar as opções como parte da montagem de ligação. Se as opções que você está passando contiverem um sinalizador vfsmount, então sim, você precisará relistar os sinalizadores vfsmount. Você pode pensar em "superblock flag" como significando que faz parte do sistema de arquivos subjacente, e "vfsmount flag" como significando que é parte do kernel (embora isso não seja tecnicamente verdade, já que o kernel é aquele que reforça ambos na realidade) .

Você precisa fazer isso com argumentos como noexec , nodev ou nosuid , porque eles se aplicam por sistema de arquivos (veja este tópico na lista de discussão do kernel para obter boas informações).

$ truncate -s 10M container
$ mkfs.ext4 container
$ mkdir mountpoint binded
$ sudo mount -o loop container mountpoint
$ sudo chown "$EUID" mountpoint
$ sudo mount -o bind mountpoint binded
$ cat > mountpoint/script << 'EOF'
> #!/bin/bash
> echo "This works."
> EOF
$ chmod +x mountpoint/script
$ binded/script 
This works.
$ sudo mount -o remount,noexec mountpoint
$ binded/script
This works.
$ mountpoint/script
bash: mountpoint/script: Permission denied

Observe que, apesar de ser o mesmo script, noexec está sendo imposto apenas por sistema de arquivos. Isso ocorre porque é um sinalizador vfsmount, não um sinalizador de superblock - ou seja, é uma funcionalidade do kernel, não do sistema de arquivos.

Observe como a saída de mount para os dois pontos de montagem se parece depois disso, e que noexec não foi transferido:

$ mount
[...]
/tmp/tmp.hoiHQYPEFX/container on /tmp/tmp.hoiHQYPEFX/mountpoint type ext4 (noexec,relatime,data=ordered)
/tmp/tmp.hoiHQYPEFX/container on /tmp/tmp.hoiHQYPEFX/binded type ext4 (relatime,data=ordered)

Se nós remontarmos a ligação propriamente dita com noexec , no entanto, isso funciona como esperado:

$ sudo mount -o remount,noexec binded
$ mount
[...]
/tmp/tmp.hoiHQYPEFX/container on /tmp/tmp.hoiHQYPEFX/mountpoint type ext4 (noexec,relatime,data=ordered)
/tmp/tmp.hoiHQYPEFX/container on /tmp/tmp.hoiHQYPEFX/binded type ext4 (noexec,relatime,data=ordered)

As opções que são subjacentes aos atributos do sistema de arquivos, no entanto, geralmente não precisam ser feitas novamente na montagem da ligação (e provavelmente irão gerar um erro, uma vez que muitas das opções suportadas são definidas pelo sistema de arquivos). Um simples para demonstrar é ro , a opção somente leitura, mas isso também se aplica a outros sinalizadores de superblocos.

$ sudo mount -o remount,ro mountpoint
$ > mountpoint/test
bash: mountpoint/test: Read-only file system
$ > binded/test
bash: binded/test: Read-only file system

Note que, desta vez, a bandeira é transportada automaticamente:

$ mount
[...]
/tmp/tmp.hoiHQYPEFX/container on /tmp/tmp.hoiHQYPEFX/mountpoint type ext4 (ro,noexec,relatime,data=ordered)
/tmp/tmp.hoiHQYPEFX/container on /tmp/tmp.hoiHQYPEFX/binded type ext4 (ro,noexec,relatime,data=ordered)