Localização idiomática para sockets baseados em ficheiros em sistemas Debian

9

Eu estou escrevendo um processo daemon para um sistema Debian em C que usa um Soquete de Domínio Unix .

Se o diretório de trabalho do processo do daemon for o diretório raiz, existe um diretório idiomático para colocar o soquete no sistema de arquivos?

    
por recursion.ninja 24.08.2013 / 21:30

1 resposta

15

Eles são comumente encontrados em /tmp ou em um subdiretório dele. Note que tudo em /tmp está sujeito a eliminação no desligamento - não que seja necessariamente apagado, apenas tome cuidado, pois pode ser , então se você usar isso, verifique se você tem que criar seu subdiretório cada vez. Você desejará usar um subdiretório se quiser restringir o acesso por meio de permissões, pois /tmp é legível pelo mundo.

/run e /var/run (que podem ser ligados simbolicamente juntos) são usados de maneira similar, mas eles geralmente são montados como sistemas de arquivos tmpfs - o que significa que eles são criados na inicialização e residem na memória. >, não em disco (portanto, não use isso como um local para despejar quantidades copiosas de dados). Para um soquete de tempo de execução, provavelmente é uma boa escolha.

Observe que /run e todos os outros diretórios mencionados aqui exceto /tmp , só podem ser gravados pelo usuário root. Para um processo de sistema, isso é bom, mas se o aplicativo puder ser executado por um usuário não privilegiado, você deseja usar /tmp ou criar um diretório permanente em algum lugar e definir permissões, ou usar um local no diretório do usuário. $ HOME.

É possível criar um diretório em /usr/share (ou /usr/local/share ) durante a instalação. Diretórios e conteúdos não são potencialmente coletados através de inicializações, como seriam em /tmp ou /run . No entanto, como jordanm aponta nos comentários, /usr pode ser montado como somente leitura e as diretrizes da hierarquia do sistema de arquivos linux reflect this . É claro que não pode ser somente leitura quando seu aplicativo é instalado, então se você estiver confortável criando um soquete aí, você pode deixá-lo e usá-lo mais tarde (você ainda será capaz de gravar no soquete mesmo que o arquivo é somente leitura).

Se você quiser em algum lugar persistente em inicializações que não serão montadas somente para leitura, /etc é uma aposta bastante segura, já que isso é frequentemente usado para configurações e reconfigurações em todo o sistema. OTOH, é possível ter sistemas onde o dispositivo subjacente a todo o sistema de arquivos raiz é somente leitura (por exemplo, sistemas embarcados), com / tmp e / run em outro dispositivo (provavelmente: tmpfs na memória). Então, as duas estratégias mais robustas parecem ser:

  • Instale o soquete em um local permanente quando o aplicativo for instalado.

  • Crie um diretório em /run ou /var/run no tempo de execução e coloque o soquete lá.

  • Faça o mesmo somente em /tmp .

A vantagem do primeiro é que, não importa o que, uma vez que o aplicativo é instalado, você terá um soquete para usar. A vantagem do segundo é que ele pode ser mais propício para a programação sã. A vantagem do terceiro é que não requer privilégios de superusuário. Deve ser fácil mudar de uma implementação para outra se você mudar de ideia mais tarde.

Finalmente, quando o BatchyX é gerado, você deve pelo menos oferecer uma opção de configuração para isso, voltando a sua escolha de padrão.

    
por 24.08.2013 / 21:48