Estou escrevendo um processo de daemon para um sistema Debian C
que usa um soquete de domínio Unix .
Se o diretório de trabalho do processo daemon for o diretório raiz, existe um diretório idiomático para colocar o soquete no sistema de arquivos?
Estou escrevendo um processo de daemon para um sistema Debian C
que usa um soquete de domínio Unix .
Se o diretório de trabalho do processo daemon for o diretório raiz, existe um diretório idiomático para colocar o soquete no sistema de arquivos?
Respostas:
Eles são comumente encontrados em /tmp
ou em um subdiretório. Note-se que tudo em /tmp
está sujeito a apagamento no desligamento - não que necessariamente é apagada, apenas cuidado que pode ser , por isso, se você usar isso, verifique se você tem que criar seu subdiretório de cada vez. Você desejará usar um subdiretório se desejar restringir o acesso por meio de permissões, pois /tmp
é legível mundialmente.
/run
e /var/run
(que podem ser vinculados juntos) são usados de maneira semelhante, mas geralmente são montados como sistemas de arquivos tmpfs - o que significa que são criados na inicialização e residem na memória , não no disco (portanto, não use isso como um local para despejo). grandes quantidades 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ão graváveis apenas pela raiz. Para um processo do sistema, isso é bom, mas se o aplicativo pode 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 nele ou usar um local no $ HOME do usuário.
É possível criar um diretório em /usr/share
(ou /usr/local/share
) durante a instalação. Os diretórios e o conteúdo não são potencialmente colhidos entre as botas como seriam /tmp
ou /run
. No entanto, como jordanm aponta nos comentários, /usr
pode ser montado como somente leitura e as diretrizes de hierarquia do sistema de arquivos linux refletem isso . Obviamente, ele não pode ser somente leitura quando o aplicativo estiver instalado; portanto, se você estiver confortável criando um soquete, poderá deixá-lo e usá-lo mais tarde (você ainda poderá gravar no soquete, mesmo que o arquivo é somente leitura).
Se você deseja um local persistente entre as botas que não serão montadas como somente leitura, /etc
é uma aposta bastante segura, pois geralmente é usada para configurações e reconfigurações em todo o sistema. OTOH, é possível ter sistemas nos quais o dispositivo subjacente a todo o sistema de arquivos raiz é somente leitura (por exemplo, sistemas incorporados), com / tmp e / executado em outro dispositivo (provavelmente: tmpfs na memória). Portanto, as duas estratégias mais robustas parecem ser:
Instale o soquete em um local permanente quando o aplicativo estiver instalado.
Crie um diretório em /run
ou /var/run
em tempo de execução e colocar a tomada lá.
Faça a mesma coisa apenas em /tmp
.
A vantagem do primeiro é que, não importa o que, uma vez instalado o aplicativo, você terá um soquete para usar. A vantagem do segundo é que ele pode ser mais propício à programação sã. A vantagem do terceiro é que ele não requer privilégios de superusuário. Deve ser fácil mudar de uma implementação para outra se você mudar de idéia mais tarde.
Finalmente, como o BatchyX criou, você deve pelo menos oferecer uma opção de configuração para isso, recorrendo à sua opção padrão.
/run
ou /var/run
também é frequentemente usado para processos raiz.
/tmp
. Vou editar que no.
/usr
pode ser montado como somente leitura. Os arquivos nunca devem ser criados lá em tempo de execução. As outras sugestões são boas.
/tmp/.APPNAME/.APPSOCK
porque o daemon não precisa de dados persistentes.
/tmp
e /run
, é que apenas o root possui permissões de gravação /run
.