NGINX lit des files avec la permission d'Apache, est-ce faux?

J'ai un server – S1 – utilisant Apache comme server web, et un autre server – S2 – exécutant NGINX comme server Web. S2 est monté dans S1 et S1 est en train de download des files vers S2 en utilisant NFS.

Ainsi, les nouveaux files ajoutés dans le server NGINX, S2, ont propriétaire et groupe d'Apache. Je n'ai eu aucun problème avec les files de service, tout fonctionne bien, mais est-ce un problème de security que je lis des files Apache en utilisant NGINX? Est-ce mal? Si oui, quels choix ai-je?


UPDATE 1: L'user défini pour NGINX dans le file de configuration est nginx, pas apache.

Pour chaque access (lecture / écriture) à un file sur le server NFS, le client partage l'ID user et l'ID de groupe de l'user sur le server NFS. Ce n'est que si le server NFS confirme que l'ID user et l'ID de groupe peut effectivement accéder au file, que la request est transmise.

Pour votre question de:

Ainsi, les nouveaux files ajoutés dans le server NGINX, S2, ont propriétaire et groupe d'Apache. Je n'ai eu aucun problème avec les files de service, tout fonctionne bien, mais est-ce un problème de security que je lis des files Apache en utilisant NGINX? Est-ce mal? Si oui, quels choix ai-je?

Comment, en premier lieu, NGINX peut-il accéder aux files créés par Apache? Ici, je suppose que le process Apache dans S1 crée les files. Et les files créés sont lisibles dans le monde entier (?). Si c'est le cas, cela pourrait être une question de security, selon votre context. En règle générale, les files créés par le process Apache sont lisibles dans le monde entier, sauf si le script qui a initié la création du file a également du code pour modifier explicitement les permissions. Vous voudrez peut-être jeter un coup d'oeil dessus.

Il se peut que l' user id et l' group id de group id d'Apache sur S1 correspondent à ceux de user id et de user id group id de NGINX sur S2. Ou si ce n'est pas le cas, les directorys qui contiennent ces files sont lisibles dans le monde entier avec read and executable bits turned on (un souci de security supplémentaire), de sorte que n'importe qui peut accéder à ces directorys.

Si NGINX et Apache fonctionnent avec des ports privilégiés, vous pouvez être extrêmement prudent. Toute escalade de privilèges identifiée ou vulnérabilité d'exploitation racine de vos versions en cours d'exécution de NGINX / Apache pourrait permettre à un pirate d'accéder à votre server. Si NGINX / Apache contient des données très sensibles, vous pouvez y accéder via l'autre server.

Bien que le monde extérieur ne sache peut-être pas que le process NGINX partage les mêmes dossiers qu'Apache, toute personne disposant d'un access shell local à S1 ou S2 peut éventuellement utiliser les vulnérabilités pour accéder à l'autre server.

S'il n'y a pas d'autre option que de partager les files entre les servers / process, vous pouvez consulter: – les permissions de lecture et d'écriture du file – les permissions d'access aux dossiers

Si les files partagés sont des files sources, il est recommandé qu'ils font partie du référentiel de contrôle de version (comme GIT) et que le dernier code est extrait aux deux locations (ce qui signifie que vous conservez deux copys).

Si votre cas d'utilisation est connu, de meilleures alternatives peuvent provenir d'autres personnes.