Qual é a diferença entre / tmp e / run?

De acordo com o FHS-3.0 , /tmpé para arquivos temporários e /runpara dados variáveis ​​em tempo de execução. Os dados /rundevem ser excluídos na próxima inicialização, o que não é necessário /tmp, mas os programas ainda não devem assumir que os dados /tmpestarão disponíveis no próximo início do programa. Tudo isso parece muito parecido comigo.

Então qual é a diferença entre os dois? Por qual critério um programa deve decidir se coloca /tmpou não dados temporários /run?

De acordo com a ESF:

Os programas podem ter um subdiretório de /run; isso é recomendado para programas que usam mais de um arquivo de tempo de execução.

Isso indica que a distinção entre "programas do sistema" e "programas comuns" não é um critério, nem a vida útil do programa (como processo de execução longa versus execução curta).

Embora a lógica a seguir não seja dada na ESF, /runfoi introduzida para superar o problema que /varfoi montado tarde demais, de modo que truques sujos eram necessários para /var/rundisponibilizar com antecedência suficiente. No entanto, agora, ao /runser apresentado, e dada sua descrição na ESF, não parece haver uma razão clara para ter ambos /rune /tmp.

Não há razão para ter ambos / run e / tmp

Eu acho que você está certo. /tmpestá essencialmente obsoleto agora temos /run. Se o seu programa estiver em condições de fazê-lo (o que exige que ele tenha sido instalado como uma operação privilegiada), hoje em dia você usaria um subdiretório /run. Isto é por razões de segurança.

Por exemplo, o daemon de impressão CUPS não é executado como root, mas geralmente é instalado a partir de um pacote do SO. O pacote instala /usr/lib/tmpfiles.d/cups.confe systemd-tmpfilescria um diretório que ele pode acessar. Como o diretório está sob /run, o nome não pode ter sido reivindicado maliciosamente por um usuário sem privilégios, diferente do /tmpque é gravável no mundo.

"Programas não privilegiados" que não podem ser usados /rundiretamente

A distinção real é se o seu programa estiver sendo executado por um usuário arbitrário e sem privilégios, com seu próprio ID de usuário. Mas você geralmente ainda não deseja usar /tmp, porque pode ser acessado por outros usuários não privilegiados. Você prefere usar $XDG_RUNTIME_DIR. Normalmente, isso é implementado como /run/user/$(id -u)- portanto, também é um subdiretório /run. A localização não é garantida; programas sempre devem usar a variável de ambiente.

/tmpseria útil apenas para cooperação ad-hoc entre diferentes usuários não privilegiados no sistema. Esses sistemas ad-hoc são vulneráveis ​​a um usuário mal-intencionado que se recusa a cooperar e estraga tudo para todos :). Um exemplo seria usuários sem privilégios que decidem executar uma versão do talkdaemon, usando um soquete unix.

Informação original de Lennart Poettering

Observe que a lista de verificação de Poettering abaixo alegou que /tmpseria útil para "arquivos pequenos", enquanto que /rundeveria ser usada apenas para "primitivas de comunicação". Também não acho que essa distinção seja verdadeira. O garoto-propaganda de /runé udev, e tenho certeza que /run/udevinclui bancos de dados internos. Depois de ter um /rundiretório, acho que ninguém quer seguir a distinção reivindicada e criar outro diretório, para desordenar /tmp. Então, na prática, usamos apenas /runhoje em dia.

O uso de namespaces compartilhados graváveis ​​em todo o mundo [como / tmp] para fins de comunicação sempre foi problemático, pois para estabelecer a comunicação você precisa de nomes estáveis, mas os nomes estáveis ​​abrem as portas para ataques de DoS. Isso pode ser corrigido parcialmente, estabelecendo diretórios por aplicativo protegidos para determinados serviços durante a inicialização antecipada (como fazemos no X11), mas isso corrige apenas parcialmente o problema, pois isso funciona corretamente se todas as instalações de pacotes forem seguidas por uma reinicialização.

...

Outro recurso do Fedora (para o Fedora 17) mudou a semântica do / tmp para muitos serviços do sistema para torná-los mais seguros, isolando os namespaces / tmp dos vários serviços

...

Como / tmp não é mais necessariamente um espaço para nome compartilhado, geralmente é inadequado como local para primitivas de comunicação.

...

[/ run] tem a garantia de ser um tmpfs e, portanto, é liberado automaticamente nas botas. Nenhuma limpeza automática é feita além disso.

...

Aqui está um guia aproximado de como sugerimos que você (um desenvolvedor de aplicativos Linux) escolha o diretório certo para usar:

1. Você precisa de um local para colocar seu soquete (ou outra primitiva de comunicação) e seu código é privilegiado: use um subdiretório abaixo / execute. (Ou abaixo de / var / run para compatibilidade extra.)
2. Você precisa de um local para colocar seu soquete (ou outra primitiva de comunicação) e seu código é executado sem privilégios: use um subdiretório abaixo de $ XDG_RUNTIME_DIR.
3. Você precisa de um local para colocar seus downloads e downloads maiores em andamento e executar sem privilégios: use $ XDG_DOWNLOAD_DIR.
4. Você precisa de um local para colocar arquivos de cache que devem ser persistentes e executados sem privilégios: use $ XDG_CACHE_HOME.
5. Nada disso se aplica e você precisa colocar um arquivo pequeno que não precise de persistência: use $ TMPDIR com um fallback em / tmp. E use mkstemp () e mkdtemp () e nada caseiro.
6. Caso contrário, use $ TMPDIR com um fallback em / var / tmp. Use também mkstemp () / mkdtemp ().

Observe que essas regras acima são sugeridas apenas por nós. Essas regras levam em consideração tudo o que sabemos sobre esse tópico e evitam problemas com distribuições atuais e futuras, tanto quanto podemos vê-las. Por favor, considere atualizar seus projetos para seguir essas regras e tenha em mente se você escrever um novo código.

Uma coisa que gostaríamos de enfatizar é que / tmp e / var / tmp com mais frequência do que não são, na verdade, a escolha certa para a sua utilização. Existem usos válidos desses diretórios, mas muitas vezes outro diretório pode realmente ser o melhor lugar. Portanto, tenha cuidado, considere as outras opções, mas se você optar por / tmp ou / var / tmp, certifique-se de usar mkstemp () / mkdtemp ().

Nós meio que escapamos do /tmpsoquete herdado usado pelo sistema X window, como descrito acima. Eu interpretei errado tmpfiles.d/x11.conf. Parece mais com a cooperação :). Presumo que o código foi auditado, de modo que a negação de serviço é a pior coisa que pode acontecer.

Os diretórios /tmpe /usr/tmp(mais tarde /var/tmp) costumavam ser o depósito de lixo para tudo e para todos. O único mecanismo de proteção para arquivos nesses diretórios é o bit que restringe a exclusão ou renomeação de arquivos para seus proprietários. Como o marcelm apontou em um comentário, não há, em princípio, nada que impeça alguém de criar arquivos com nomes usados ​​pelos serviços (como nginx.pidou sshd.pid). (Na prática, os scripts de inicialização podem remover esses arquivos falsos primeiro.)

/runfoi estabelecido para dados de tempo de execução não persistentes de serviços de longa duração, como bloqueios, soquetes, arquivos pid e similares. Como não é gravável para o público, protege os dados de tempo de execução do serviço da bagunça /tmpe dos trabalhos que são limpos lá. Na verdade: duas distribuições que eu corro (sem trocadilhos) têm permissões 755 /run, enquanto /tmpe /var/tmp(e, /dev/shmnesse caso) têm permissões 1777.

/tmpé o local para criação de arquivos e diretórios temporários. Não é útil armazenar "nomes conhecidos" (ou seja, nomes que outro processo poderia ter conhecimento sem que você tivesse que transmitir o nome de alguma forma) porque ninguém possui propriedade sobre o espaço para nome; qualquer um pode criar arquivos lá. Como tal, você geralmente o utiliza quando possui um utilitário que precisa de um arquivo (por exemplo, não um canal ou outro) como entrada ou saída, onde qualquer nome (gerado aleatoriamente) funcionará desde que você o passe.

Historicamente, algumas coisas (como X) violaram esse princípio e colocaram nomes conhecidos (como .X11-unix) /tmp. Obviamente, isso é um buggy e permite que qualquer usuário faça o serviço de DoS, precisando simplesmente fazê-lo correndo para criar um arquivo com o nome desejado primeiro. Essas coisas pertencem a /run(ou equivalentemente, /var/runse você não assinar o revisionismo do Freedesktop.org). É claro que o melhor seria corrigi-los para não usar nomes conhecidos em um espaço para nome global, mas passar um nome de caminho.

De acordo com o padrão de hierarquia do sistema de arquivos,

• /run é para dados variáveis ​​de tempo de execução, ou seja, informações sobre o sistema em execução desde a reinicialização
• /tmp é um local genérico para arquivos temporários.

Portanto, qualquer coisa relacionada ao status do daemon, usuários conectados, dispositivos removíveis montados etc. entraria /runenquanto os arquivos temporários criados por um programa entrariam /tmp.

Edit: como apontado por @JdeBP no comentário abaixo,

O FHS permite coisas como a configuração convencional de tarefas cron que limpam regularmente /tmparquivos "antigos"; sem esses mecanismos destinados /run. Daí o limite draconiano sobre o que os programas podem esperar da vida de qualquer coisa colocada /tmp. Embora os programas possam esperar que os arquivos permaneçam mais tempo em /runum sistema continuamente ativo, também é esperado que eles se arrumam mais lá.