En supposant qu'une `` application Web '' s'exécute sur un serveur (comme apache, nginx, etc.) et qu'elle est écrite dans un langage de script dynamique (comme PHP, Ruby, etc.), vous vous méprenez sur qui est `` l'utilisateur ''.
L'utilisateur n'est pas la personne qui est connectée à votre application - cela, et son rôle dans l'application (admin, etc.) est complètement hors de propos pour le scénario. L'utilisateur est l'utilisateur système Linux sous lequel le processus s'exécute. Le code de votre site Web est exécuté comme un seul utilisateur - il peut s'agir de l'utilisateur de votre serveur Web (ce qui n'est pas vraiment une bonne chose), ou il peut s'agir d'un utilisateur spécifique à votre site (ce qui est beaucoup mieux).
Sous Linux, les utilisateurs appartiennent à des groupes - nous pouvons ajouter un utilisateur à un autre groupe et attribuer des privilèges à ce groupe.
Une bonne configuration aura votre serveur exécuté comme un seul utilisateur (appelons cet utilisateur «serveur Web») et votre langage de script dynamique exécuté (par exemple via FastCGI) comme son propre utilisateur (un utilisateur par site - appelons notre premier utilisateur «site1») .
Pour servir vos fichiers, le serveur Web doit y avoir accès et le langage de script doit y avoir accès. Cela signifie que 'site1' et 'webserver' doivent pouvoir lire vos fichiers. Cependant, un seul d'entre eux peut «posséder» les fichiers. Le propriétaire est l '«utilisateur» (utilisateur, groupe, autre). Nous avons également besoin de notre langage de script pour pouvoir écrire dans le répertoire (et lire les fichiers qu'il a écrits). L'utilisateur 'site1' a donc besoin d'autorisations de lecture et d'écriture. Puisque nous voulons que les autorisations de groupe et autres soient aussi restrictives que possible, notre «propriétaire» sera «site1», et les autorisations d'utilisateur correspondantes seront lues et écrites.
Étant donné que nous ne pouvons pas spécifier les autorisations pour notre serveur Web en tant qu’autre «utilisateur», nous ajouterons «serveur Web» au groupe «site1» (vous pouvez bien sûr créer un groupe différent contenant à la fois «site1» et «serveur Web». Tout les membres de ce groupe se verront attribuer les mêmes autorisations. Les autorisations les plus laxistes (de l'utilisateur, du groupe ou d'un autre ensemble) seront appliquées à n'importe quel utilisateur pour déterminer ses autorisations.
Il convient de noter qu'une bonne configuration ne devrait pas exiger que les fichiers aient des autorisations d'exécution pour un langage dynamique. Les fichiers ne sont pas exécutés directement, mais sont plutôt lus dans un interpréteur - seules les autorisations de lecture sont nécessaires pour exécuter un script typique (celui qui n'écrit rien).
L'autorisation «exécuter» sur les répertoires a une signification différente - elle permet la traversée sans pouvoir lire le contenu. Afin de pouvoir lire un fichier dans un répertoire, un utilisateur doit avoir des autorisations «exécuter» sur CHAQUE répertoire au-dessus.
Pour une application Web, chaque fichier doit avoir des autorisations de lecture par son propriétaire - sinon, c'est un fichier assez inutile. Qu'un utilisateur ou un administrateur télécharge des fichiers (via votre application Web), le «propriétaire» (c'est-à-dire le langage dynamique) a besoin d'autorisations d'écriture. Une configuration efficace tentera de servir des fichiers statiques directement via le serveur Web, car les langues dynamiques ont tendance à être lentes à lire des fichiers volumineux et à reproduire le contenu. Le serveur Web a donc besoin d'un accès en lecture à vos fichiers statiques.
Par conséquent, les autorisations de fichier minimales peuvent être:
- Un fichier dans un répertoire où les fichiers statiques téléchargés par l'utilisateur (fichiers images / swf / js) résideront: 640
- Un fichier dans un répertoire où les fichiers statiques téléchargés par l'administrateur (fichiers images / swf / js) résideront: 640
- Un fichier dans un répertoire où résident les bibliothèques utilisées dans l'application: 400 (ou 440)
- Un fichier dans un répertoire où résideront les scripts côté serveur exécutables / navigables: 400 (ou 440)
- Un fichier dans un répertoire où les fichiers déjà existants (txt ou xml) seront édités par code côté serveur: 640 ou 600
- (dépend si le serveur Web les affichera, parfois non modifiés)
Tandis que les autorisations minimales de répertoire peuvent être:
- Un répertoire où les fichiers statiques téléchargés par l'utilisateur (fichiers images / swf / js) résideront: 750
- Un répertoire où les fichiers statiques téléchargés par l'administrateur (fichiers images / swf / js) résideront: 750
- Un répertoire où résident les bibliothèques utilisées dans l'application: 500 (ou 550) [devrait être au moins 510]
- Un répertoire où résideront les scripts côté serveur exécutables / navigables: 500 (ou 550) [devrait être au moins 510]
- Un répertoire où les fichiers déjà existants (txt ou xml) seront édités par code côté serveur: 750 ou 700
- (dépend si le serveur Web servira des fichiers d'ici, non modifiés parfois)
Encore une fois - votre serveur Web doit avoir des autorisations «exécuter» sur chaque répertoire au-dessus de celui auquel il doit accéder - donc même si le serveur Web ne sert pas les fichiers d'un répertoire donné, nous devons lui accorder des autorisations d'exécution.
Il est assez courant de donner au serveur Web un accès en lecture à la plupart des fichiers (modifiez donc ces 500 à 550). Les autorisations par défaut `` assez sécurisées '' sont généralement 755 pour les répertoires et 644 pour les fichiers - pas d'autorisations d'exécution, tout le monde peut lire et seul l'utilisateur peut écrire - vous remarquerez que la grande majorité des fichiers sur un système linux ont ces autorisations.
Gardez à l'esprit que les «autres» autorisations se réfèrent à tout utilisateur du système qui n'est pas le propriétaire ou dans le groupe (c'est-à-dire tous les autres utilisateurs du système). Garder vos «autres» autorisations restrictives est bon, car ces utilisateurs sont inconnus - vous ne leur avez pas explicitement donné l'autorisation. Les autres autorisations sont souvent les plus faciles à utiliser sur un système compromis (par exemple, l'une des raisons pour lesquelles / tmp est une cible commune).
Dans le contexte de ce qui précède, je ne pense pas que vos deux dernières questions soient pertinentes. Définissez vos autorisations de répertoire sur 550 (et les autorisations de fichier sur 440), puis accordez à l'utilisateur les autorisations d'écriture pour tous les répertoires dans lesquels votre application va écrire (par exemple, répertoire: 750; fichier: 640).
(Vous aurez évidemment besoin d'autorisations en écriture pour télécharger les fichiers - mais si vous le souhaitez, vous pouvez les supprimer par la suite - sans doute cependant, si quelqu'un écrit dans un répertoire que seul le propriétaire peut écrire - votre compte a été compromis - qui en est un des raisons du maintien des autorisations restrictives).