Início / server / Perguntas / 868682
Accepted
Tom Hale
Asked: 2017-08-15 23:47:44 +0800 CST

Implicações de `mount --make-private /`

  • 772

Atualmente, /tem propagação de montagem compartilhada:

# findmnt -o TARGET,PROPAGATION /
TARGET PROPAGATION
/      shared

Estou pensando em alterá-lo para privatepermitir mount --movetrabalhar em sistemas de arquivos montados em /mnte /media.

(Eu quero usar mount --moveem vez do inseguro umount --lazy)

Sem /ser private, mount --movevai reclamar com algo como:

# mount --move /mnt/mountpoint /mnt/moved
mount: /mnt/moved: bad option; moving a mount residing under a shared mount is unsupported.

  1. Por que é / sharedpor padrão?

  2. Quais são as implicações de mudar /para ser private?

linux

1 respostas

  1. Best Answer

    O sinalizador de propagação é alterado por systemd. De man 7 mount_namespaces:

    systemd(1) remonta automaticamente todos os pontos de montagem como MS_SHARED na inicialização do sistema. Assim, na maioria dos sistemas modernos, o tipo de propagação padrão é na prática MS_SHARED.

    De https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L406

      /* Mark the root directory as shared in regards to mount propagation. The kernel defaults to "private", but we
     * think it makes more sense to have a default of "shared" so that nspawn and the container tools work out of
     * the box. If specific setups need other settings they can reset the propagation mode to private if
     * needed. Note that we set this only when we are invoked directly by the kernel. If we are invoked by a
     * container manager we assume the container manager knows what it is doing (for example, because it set up
     * some directories with different propagation modes). */
    if (detect_container() <= 0)
            if (mount(NULL, "/", NULL, MS_REC|MS_SHARED, NULL) < 0)

    As implicações dependem de seus casos de uso específicos. Eu acho que a maioria dos programas continuará a funcionar. No entanto, sua alteração será substituída na reinicialização.

    Você pode ler mais no comentário de Lennart Poettering em https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739593

    Aqui está uma parte dele:

    b) Se você corrigir o systemd para voltar ao MS_PRIVATE para o diretório raiz, você desativa a propagação para contêineres e ninguém mais pode optar por ele para seu namespace específico.

    Vantagem: você não precisa corrigir aqueles poucos programas que atualmente assumem que o diretório raiz é MS_PRIVATE e não desassociam as coisas.

    Desvantagem: os aplicativos ainda estão quebrados para quem muda para MS_SHARED para /. Você, portanto, cobre apenas os casos de uso em que as pessoas não se dissociam. Você quebra o caso de uso onde as pessoas querem que a propagação aconteça.

    • 3

relate perguntas