Remontar somente leitura sem alterar outras opções

Question

Trabalhando em systemd-shutdown , está usando mount() para remontar os sistemas de arquivos como somente leitura.

/* MS_REMOUNT requires that the data parameter
 * should be the same from the original mount
 * except for the desired changes. Since we want
 * to remount read-only, we should filter out
 * rw (and ro too, because it confuses the kernel) */
...filter_options(m->options, "rw
/* MS_REMOUNT requires that the data parameter
 * should be the same from the original mount
 * except for the desired changes. Since we want
 * to remount read-only, we should filter out
 * rw (and ro too, because it confuses the kernel) */
...filter_options(m->options, "rw%pre%ro%pre%", NULL, NULL, &options);

...mount(NULL, m->path, NULL, MS_REMOUNT|MS_RDONLY, options)...
ro%pre%", NULL, NULL, &options);

...mount(NULL, m->path, NULL, MS_REMOUNT|MS_RDONLY, options)...

Mas quando olhei para strace mount -oremount,rw /boot , a chamada do sistema mount foi passada como NULL como seu último argumento. Isso mostra que não é realmente necessário copiar e manipular a sequência de caracteres antiga?

    

Answer 1

Não.

Se você editar /etc/fstab e adicionar uma opção não genérica foo , então /sbin/mount passará "foo" como o último argumento para mount() . No seu exemplo, estava passando NULL, mas acho que significava a string vazia "" . Presumivelmente, eles têm o mesmo efeito.

Aparentemente, o /sbin/mount se comportará de maneira diferente se você passar um caminho e um dispositivo (!).

The remount functionality follows the standard way the mount command works with options from fstab. This means that mount does not read fstab (or mtab) only when both device and dir are specified.

 mount -o remount,rw /dev/foo /dir

After this call all old mount options are replaced and arbitrary stuff from fstab (or mtab) is ignored, except the loop= option which is internally generated and maintained by the mount command.

 mount -o remount,rw  /dir

After this call, mount reads fstab and merges these options with the options from the command line (-o). If no mountpoint is found in fstab, then a remount with unspecified source is allowed.

Por implicação, parece que o último caso também sobrescreve quaisquer opções atuais do ponto de montagem.

O código citado na pergunta é um pouco suspeito. Parece redefinir os sinalizadores de montagem. Comportamento atual:

Remounting an existing mount

... The mountflags and data arguments should match the values used in the original mount() call, except for those parameters that are being deliberately changed.

então é provavelmente de onde veio o comentário.

The following mountflags can be changed: MS_LAZYTIME, MS_MANDLOCK, MS_NOATIME, MS_NODEV, MS_NODIRATIME, MS_NOEXEC, MS_NOSUID, MS_RELATIME, MS_RDONLY, and MS_SYNCHRONOUS.

Eu acho que o código está atualmente funcionando ok. Remontar como somente leitura evita perguntas sobre gravações subseqüentes, ou um remontamento de leitura-gravação sendo negado porque o blockdev é somente leitura. E systemd-shutdown deveria ter enviado SIGKILL para qualquer outro processo com acesso ao sistema de arquivos por este ponto, então provavelmente podemos ignorar as opções de segurança como o NOEXEC.

Attempts to change the setting of the MS_DIRSYNC flag during a remount are silently ignored.

Embora isso implique que outros sinalizadores não sejam silenciosamente ignorados e possam fazer com que a chamada falhe se eles não corresponderem, não acho que o código do kernel principal faça algo assim.

Since Linux 3.17, if none of MS_NOATIME, MS_NODIRATIME, MS_RELATIME, or MS_STRICTATIME is specified in mountflags, then the remount operation preserves the existing values of these flags (rather than defaulting to MS_RELATIME).

Since Linux 2.6.26, this flag can also be used to make an existing bind mount read-only by specifying mountflags as:

MS_REMOUNT | MS_BIND | MS_RDONLY

Acho que também o systemd-shutdown não processou o fstab exatamente da mesma forma que mount -oremount,ro /boot teria :). (Os scripts antigos do sysvinit estão ok, pelo menos no Debian, porque eles não usam o remount RO para qualquer coisa que não seja o sistema de arquivos raiz).