En supposant qu'une "application web" fonctionne sur un serveur (comme apache, nginx, etc.) et qu'elle est écrite dans un langage de script dynamique (comme PHP, Ruby, etc.), vous avez mal compris qui est l'"utilisateur".
L'utilisateur n'est pas la personne qui est connectée à votre application - cela, ainsi que son rôle dans l'application (administrateur, etc.), n'est absolument pas pertinent pour le scénario. L'utilisateur est l'utilisateur du système linux sous lequel le processus est exécuté. Le code de votre site web est exécuté sous un seul utilisateur - il peut s'agir de l'utilisateur de votre serveur web (ce qui n'est pas vraiment une bonne chose), ou d'un utilisateur spécifique à votre site (ce qui est bien mieux).
Sur linux, les utilisateurs appartiennent à des groupes - nous pouvons ajouter un utilisateur à un autre groupe et attribuer des privilèges à ce groupe.
Dans une bonne configuration, votre serveur s'exécutera sous un seul utilisateur (appelons cet utilisateur "webserver") et votre langage de script dynamique s'exécutera (par exemple via FastCGI) sous 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 "serveur web" doivent être en mesure de lire vos fichiers. Cependant, un seul d'entre eux peut "posséder" les fichiers. Le propriétaire est l'"utilisateur" (dans user, group, other). Nous avons également besoin que notre langage de script puisse écrire dans le répertoire (et lire les fichiers qu'il a écrits). L'utilisateur 'site1' a donc besoin de droits de lecture et d'écriture. Puisque nous voulons que les permissions de groupe et autres soient aussi restrictives que possible, notre 'propriétaire' sera 'site1', et les permissions d'utilisateur correspondantes seront lecture et écriture.
Puisque nous ne pouvons pas spécifier les permissions pour notre serveur web en tant qu'autre "utilisateur", nous allons ajouter "webserver" au groupe "site1" (vous pouvez bien sûr créer un groupe différent avec à la fois "site1" et "webserver"). Tous les membres de ce groupe recevront les mêmes permissions. Les permissions les plus laxistes (de l'utilisateur, du groupe, d'un autre ensemble) seront appliquées à tout utilisateur donné pour déterminer ses permissions.
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 directement exécutés, mais plutôt lus dans un interpréteur - seules des permissions de lecture sont nécessaires pour exécuter un script typique (un qui n'écrit rien).
L'autorisation "execute" sur les répertoires a une signification différente : elle permet de les parcourir sans pouvoir en lire le contenu. Pour pouvoir lire un fichier dans un répertoire, un utilisateur doit avoir les droits d'exécution sur TOUS les répertoires situés au-dessus.
Pour une application web, chaque fichier doit avoir des droits 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) doit disposer de droits d'écriture. Une configuration efficace essaiera de servir les fichiers statiques directement via le serveur web, car les langages dynamiques ont tendance à être lents à lire les fichiers volumineux et à en restituer le contenu. Le serveur web a donc besoin d'un accès en lecture à vos fichiers statiques.
Par conséquent, les autorisations minimales de fichiers peuvent être :
- Un fichier dans un répertoire où résideront les fichiers statiques téléchargés par l'utilisateur (images/swf/js) : 640
- Un fichier dans un répertoire où résideront les fichiers statiques téléchargés par l'administrateur (images/swf/js) : 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 exécutables/navigables côté serveur : 400 (ou 440)
- Un fichier dans un répertoire où les fichiers déjà existants (txt ou xml) seront édités par le code du côté serveur : 640 ou 600
- (cela dépend si le serveur web les affiche, parfois sans modification)
Alors que, les permissions minimales du répertoire peuvent être :
- Un répertoire où les fichiers statiques téléchargés par l'utilisateur (images/swf/js) résideront : 750
- Un répertoire où les fichiers statiques téléchargés par l'administrateur (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 510 au moins].
- Un répertoire où résideront les scripts exécutables/navigables côté serveur : 500 (ou 550) [devrait être 510 au moins].
- Un répertoire où les fichiers déjà existants (txt ou xml) seront édités par le code côté serveur : 750 ou 700
- (cela dépend si le serveur web va servir des fichiers à partir d'ici, parfois non modifiés)
Une fois de plus, votre serveur web doit avoir les droits d'exécution sur tous les répertoires situés au-dessus de celui auquel il doit accéder. Ainsi, même si le serveur web ne veut pas servir les fichiers d'un répertoire donné, nous devons lui accorder les droits d'exécution.
Il est assez courant de donner au serveur web un accès en lecture à la plupart des fichiers (changez donc ces 500 en 550). Les permissions par défaut "quelque peu sécurisées" sont généralement 755 pour les répertoires et 644 pour les fichiers - pas de permissions 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 permissions.
Gardez à l'esprit que les autorisations "autres" font référence à tout utilisateur du système qui n'est pas le propriétaire ou le groupe (c'est-à-dire tous les autres utilisateurs du système). Il est bon de conserver des autorisations restrictives pour les "autres", car ces utilisateurs sont inconnus - vous ne leur avez pas explicitement donné d'autorisation. Les autres permissions sont souvent les plus faciles à exploiter sur un système compromis (c'est l'une des raisons pour lesquelles /tmp est une cible courante).
Dans le contexte de ce qui précède, je ne pense pas que vos deux dernières questions soient très pertinentes. Définissez les droits d'accès aux répertoires à 550 (et les droits d'accès aux fichiers à 440), puis accordez à l'utilisateur des droits d'écriture pour tous les répertoires dans lesquels votre application écrira (c'est-à-dire répertoire : 750 ; fichier : 640).
(Vous aurez évidemment besoin de droits d'écriture pour télécharger les fichiers - mais si vous le souhaitez, vous pouvez les supprimer par la suite - on peut toutefois soutenir que si quelqu'un écrit dans un répertoire où seul le propriétaire peut écrire - votre compte a été compromis - ce qui est l'une des raisons pour lesquelles il faut conserver des autorisations restrictives).
1 votes
Je ne comprends pas pourquoi les gens PAS en utilisant des ACLs ces jours-ci ...