Para cada acesso (leitura / gravação) a um arquivo no servidor NFS, o cliente compartilha o ID do usuário e o ID do grupo do usuário no servidor NFS. Somente se o servidor NFS confirmar que o ID do usuário e o ID do grupo podem acessar o arquivo, ele permite que a solicitação passe.
Para sua pergunta:
So newly added files in the NGINX Server, S2, has owner and group of Apache. I've had no problem with serving files, everything is working fine, but is it a security issue that I'm reading Apache files using NGINX? Is it wrong at all? If yes so, what choices do I have??
Como em primeiro lugar, o NGINX é capaz de acessar arquivos criados pelo Apache? Aqui, presumo que o processo do Apache no S1 está criando os arquivos. E os arquivos criados são legíveis pelo mundo (?). Se for, isso pode ser uma questão de segurança, dependendo do seu contexto. Normalmente, os arquivos criados pelo processo Apache são legíveis por todo o mundo, a menos que o script que iniciou a criação do arquivo tenha também o código para alterar as permissões explicitamente. Você pode querer dar uma olhada nisso.
Pode haver que user id e group id do Apache no S1 correspondam a user id e group id do NGINX no S2. Ou, se esse não for o caso, os diretórios que contêm esses arquivos são legíveis por todo o mundo com read and executable bits turned on (mais uma questão de segurança), de modo que, além do Apache (no S1), qualquer pessoa pode acessar esses diretórios.
Se o NGINX e o Apache estiverem rodando com portas privilegiadas, você pode ser extremamente cuidadoso. Quaisquer vulnerabilidades identificadas de escalonamento de privilégios ou exploração de raiz de suas versões em execução do NGINX / Apache podem permitir que um hacker tenha acesso ao seu servidor. Se um dos NGINX / Apache está mantendo dados muito sensíveis, você está fornecendo uma maneira de chegar a isso através do outro servidor.
Embora o mundo externo possa não saber disso, o processo NGINX está compartilhando as mesmas pastas que o Apache, qualquer um com acesso shell local a S1 ou S2 pode eventualmente usar vulnerabilidades para obter acesso ao outro servidor.
Se não houver outra opção além de compartilhar os arquivos entre os servidores / processos, convém investigar estes: - permissões de leitura e gravação de arquivos - permissões de acesso à pasta
Se os arquivos compartilhados forem arquivos de origem, é aconselhável que eles façam parte do repositório de controle de versão (como GIT) e que o código mais recente tenha sido registrado em ambos os locais (o que significa que você está mantendo duas cópias). / p>
Se o seu caso de uso for conhecido, alternativas melhores poderão vir de outras pessoas.