Question Quelles autorisations les fichiers / dossiers de mon site Web doivent-ils avoir sur un serveur Web Linux?


C'est un Question canonique sur les autorisations de fichiers sur un serveur Web Linux.

J'ai un serveur Web Linux exécutant Apache2 qui héberge plusieurs sites Web. Chaque site Web a son propre dossier dans / var / www /.

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

Le répertoire de base / var / www / appartient à root: root. Apache s'exécute en tant que www-data: www-data. Le site Web Fabrikam est mis à jour par deux développeurs, Alice et Bob. Les deux sites Web de Contoso sont gérés par un développeur, Eve. Tous les sites Web permettent aux utilisateurs de télécharger des images. Si un site Web est compromis, l'impact doit être aussi limité que possible.

Je souhaite connaître le meilleur moyen de configurer des autorisations afin qu'Apache puisse diffuser le contenu, que le site Web soit sécurisé contre les attaques et que les développeurs puissent toujours apporter des modifications. L'un des sites Web est structuré comme suit:

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

Comment les autorisations doivent-elles être définies sur ces répertoires et fichiers? J'ai lu quelque part que vous ne devriez jamais utiliser les autorisations 777 sur un site Web, mais je ne comprends pas quels problèmes cela pourrait causer. Pendant les périodes de pointe, le site Web met automatiquement certaines pages en cache et stocke les résultats dans le dossier de cache. Tout le contenu soumis par les visiteurs du site Web est enregistré dans le dossier des téléchargements.


283
2018-02-06 01:50


origine


Ceci est destiné à être un canonique répondre à toutes les questions que nous avons sur les autorisations de site Web. - Nic
"J'ai lu quelque part que vous ne devriez jamais utiliser les autorisations 777 sur un site Web, mais que je ne comprends pas ..." - le lecteur sera-t-il en mesure de comprendre ou au moins de comparer le bien-fondé des réponses ici? Toute solution doit être basée sur des exigences spécifiques - les exigences ici ne sont pas assez spécifiques (quel est le modèle de menace) - symcbean
J'aime que vous posiez des questions sur Apache, mais que vous utilisiez les domaines généralement utilisés par Microsoft comme exemples. - gWaldo
Regarde aussi Quelle est la meilleure façon de gérer les autorisations pour l'utilisateur www-data d'apache2 dans / var / www? - Gareth
Vous pouvez vous référer ici pour des détails complets sur les autorisations requises pour être placés sur les fichiers et dossiers de sites Web sous Linux serverfault.com/questions/124800/…


Réponses:


Lorsque vous décidez des autorisations à utiliser, vous devez savoir exactement qui sont vos utilisateurs et ce dont ils ont besoin. Un serveur Web interagit avec deux types d'utilisateurs.

Authentifié les utilisateurs ont un compte utilisateur sur le serveur et peuvent se voir attribuer des privilèges spécifiques. Cela inclut généralement les administrateurs système, les développeurs et les comptes de service. Ils apportent généralement des modifications au système à l'aide de SSH ou de SFTP.

Anonyme les utilisateurs sont les visiteurs de votre site Web. Bien qu'ils ne disposent pas des autorisations nécessaires pour accéder directement aux fichiers, ils peuvent demander une page Web et le serveur Web agit en leur nom. Vous pouvez limiter l'accès des utilisateurs anonymes en faisant attention aux autorisations dont dispose le processus du serveur Web. Sur de nombreuses distributions Linux, Apache s’exécute en tant que www-data utilisateur mais cela peut être différent. Utilisation ps aux | grep httpd ou ps aux | grep apache pour voir quel utilisateur Apache utilise sur votre système.


Notes sur les permissions linux

Linux et les autres systèmes compatibles POSIX utilisent les autorisations Unix traditionnelles. Il existe un excellent article sur Wikipedia sur Permissions du système de fichiers donc je ne vais pas tout répéter ici. Mais il y a quelques choses que vous devriez être au courant.

Le bit d'exécution
Les scripts interprétés (par exemple, Ruby, PHP) fonctionnent parfaitement sans l'autorisation d'exécution. Seuls les fichiers binaires et les scripts shell ont besoin du bit d'exécution. Pour parcourir (entrer) un répertoire, vous devez avoir une autorisation d'exécution sur ce répertoire. Le serveur Web a besoin de cette autorisation pour répertorier un répertoire ou servir les fichiers qu'il contient.

Autorisations de nouveau fichier par défaut
Lorsqu'un fichier est créé, il hérite normalement de l'identifiant de groupe de celui qui l'a créé. Mais parfois, vous souhaitez que les nouveaux fichiers héritent de l'ID de groupe du dossier dans lequel ils ont été créés. Vous devez donc activer le bit SGID sur le dossier parent.

Les valeurs d'autorisation par défaut dépendent de votre umask. Umask soustrait les autorisations des fichiers nouvellement créés. Ainsi, la valeur commune de 022 entraîne la création de fichiers avec 755. Lors de la collaboration avec un groupe, il est utile de modifier votre umask en 002 afin que les fichiers que vous créez puissent être modifiés par les membres du groupe. Et si vous souhaitez personnaliser les autorisations des fichiers téléchargés, vous devez modifier umask pour apache ou exécuter chmod après le téléchargement du fichier.


Le problème avec 777

Lorsque vous chmod 777 Sur votre site Web, vous n’avez aucune sécurité. Tout utilisateur du système peut modifier ou supprimer n’importe quel fichier de votre site Web. Mais plus sérieusement, rappelez-vous que le serveur Web agit pour le compte des visiteurs de votre site Web et qu'il peut désormais modifier les mêmes fichiers qu'il est en train d'exécuter. S'il existe des vulnérabilités de programmation sur votre site Web, elles peuvent être exploitées pour altérer votre site Web, y insérer des attaques de phishing ou voler des informations à votre serveur sans que vous le sachiez.

De plus, si votre serveur fonctionne sur un port bien connu (ce qui devrait empêcher les utilisateurs non root de générer des services d'écoute accessibles au monde entier), cela signifie que votre serveur doit être démarré par root (bien que tout serveur sain puisse immédiatement passer à un compte moins privilégié une fois le port lié). . En d’autres termes, si vous exécutez un serveur Web où l’exécutable principal fait partie du contrôle de version (par exemple, une application CGI), en laissant ses autorisations (ou, d’autre part, les autorisations du répertoire contenant, car l’utilisateur peut renommer l'exécutable) à 777 permet tout utilisateur à exécuter tout exécutable en tant que root.


Définir les exigences

  • Les développeurs ont besoin d'un accès en lecture / écriture aux fichiers pour pouvoir mettre à jour le site Web.
  • Les développeurs ont besoin de lire / écrire / exécuter sur des répertoires pour pouvoir naviguer
  • Apache a besoin d'un accès en lecture aux fichiers et aux scripts interprétés
  • Apache a besoin d'un accès en lecture / exécution à des répertoires utilisables
  • Apache a besoin d'un accès en lecture / écriture / exécution aux répertoires pour le contenu téléchargé.

Maintenu par un utilisateur unique

Si seul un utilisateur est responsable de la maintenance du site, définissez-le en tant que propriétaire de l'utilisateur dans le répertoire du site Web et accordez à l'utilisateur toutes les autorisations rwx. Apache a toujours besoin d'un accès pour pouvoir traiter les fichiers. Définissez donc www-data en tant que propriétaire du groupe et accordez-lui les autorisations nécessaires.

Dans votre cas, Eve, dont le nom d'utilisateur pourrait être eve, est le seul utilisateur qui maintient contoso.com :

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Si vous avez des dossiers qui doivent être accessibles en écriture par Apache, vous pouvez simplement modifier les valeurs d'autorisation pour le propriétaire du groupe afin que www-data dispose d'un accès en écriture.

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

L'avantage de cette configuration est que cela devient plus difficile (mais pas impossible *) pour les autres utilisateurs du système de fouiller, car seuls les propriétaires d'utilisateurs et de groupes peuvent parcourir le répertoire de votre site Web. Ceci est utile si vous avez des données secrètes dans vos fichiers de configuration. Faites attention à votre umask! Si vous créez un nouveau fichier ici, les valeurs des autorisations seront probablement 755 par défaut. Vous pouvez exécuter umask 027de sorte que les nouveaux fichiers ont par défaut 640 (rw- r-- ---).


Maintenu par un groupe d'utilisateurs

Si plusieurs utilisateurs sont responsables de la maintenance du site, vous devez créer un groupe à utiliser pour l'attribution d'autorisations. Il est recommandé de créer un groupe distinct pour chaque site Web et de nommer le groupe d'après ce site.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

Dans l'exemple précédent, nous avons utilisé le propriétaire du groupe pour attribuer des privilèges à Apache, mais cette propriété est désormais utilisée pour le groupe des développeurs. Étant donné que l'utilisateur propriétaire ne nous est plus utile, sa configuration en tant que racine est un moyen simple de s'assurer qu'aucun privilège n'est protégé. Apache a toujours besoin d'un accès, nous donnons donc un accès en lecture au reste du monde.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Si vous avez des dossiers qui doivent être accessibles en écriture par Apache, vous pouvez définir Apache comme propriétaire de l'utilisateur ou comme propriétaire du groupe. De toute façon, il aura tous les accès dont il a besoin. Personnellement, je préfère en faire le propriétaire de l'utilisateur afin que les développeurs puissent toujours parcourir et modifier le contenu des dossiers de téléchargement.

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Bien que ce soit une approche commune, il y a un inconvénient. Etant donné que tous les autres utilisateurs du système bénéficient des mêmes privilèges sur votre site Web qu'Apache, il est facile pour les autres utilisateurs de naviguer sur votre site et de lire les fichiers pouvant contenir des données secrètes, tels que vos fichiers de configuration.

Vous pouvez avoir votre gâteau et le manger aussi

Cela peut être encore amélioré. Il est parfaitement légal que le propriétaire ait moins de privilèges que le groupe. Ainsi, au lieu de gaspiller le propriétaire de l'utilisateur en l'attribuant à root, nous pouvons confier Apache au propriétaire de l'utilisateur sur les répertoires et les fichiers de votre site Web. Il s’agit d’un renversement du scénario de responsable unique, mais il fonctionne tout aussi bien.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Si vous avez des dossiers qui doivent être accessibles en écriture par Apache, vous pouvez simplement modifier les valeurs des autorisations pour le propriétaire de l'utilisateur afin que www-data dispose d'un accès en écriture.

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Une chose à laquelle il faut faire attention avec cette solution est que l'utilisateur propriétaire des nouveaux fichiers correspondra au créateur au lieu d'être défini sur www-data. Ainsi, tous les nouveaux fichiers que vous créez ne seront pas lisibles par Apache jusqu'à ce que vous les chowniez.


* Séparation des privilèges Apache

J'ai déjà mentionné qu'il était en fait possible pour d'autres utilisateurs de surveiller votre site Web, quel que soit le type de privilèges que vous utilisez. Par défaut, tous les processus Apache s'exécutent sous le même utilisateur www-data. Ainsi, tout processus Apache peut lire les fichiers de tous les autres sites Web configurés sur le même serveur et même parfois y apporter des modifications. Tout utilisateur pouvant faire exécuter un script à Apache peut obtenir le même accès qu’Apache.

Pour lutter contre ce problème, il existe différentes approches de la séparation de privilège dans Apache. Cependant, chaque approche présente divers inconvénients en termes de performances et de sécurité. À mon avis, tout site ayant des exigences de sécurité élevées devrait être exécuté sur un serveur dédié plutôt que d'utiliser VirtualHosts sur un serveur partagé.


Considérations supplémentaires

Je n'en ai pas parlé auparavant, mais il est généralement déconseillé de demander aux développeurs de modifier directement le site Web. Pour les sites plus importants, il est beaucoup mieux d'avoir une sorte de système de publication qui met à jour le serveur Web à partir du contenu d'un système de contrôle de version. L’approche du responsable unique est probablement idéale, mais vous avez un logiciel automatisé au lieu d’une personne.

Si votre site Web autorise les téléchargements qui n'ont pas besoin d'être fournis, ces téléchargements doivent être stockés quelque part en dehors de la racine Web. Sinon, vous constaterez peut-être que des personnes téléchargent des fichiers censés être secrets. Par exemple, si vous autorisez les étudiants à soumettre des travaux, ils doivent être enregistrés dans un répertoire non desservi par Apache. C'est également une bonne approche pour les fichiers de configuration contenant des secrets.

Pour un site Web avec des exigences plus complexes, vous pouvez envisager l’utilisation de Listes de contrôle d'accès. Celles-ci permettent un contrôle beaucoup plus sophistiqué des privilèges.

Si les exigences de votre site Web sont complexes, vous pouvez écrire un script définissant toutes les autorisations. Testez-le soigneusement, puis conservez-le en toute sécurité. Cela pourrait valoir son pesant d'or si vous vous retrouvez parfois dans l'obligation de reconstruire votre site Web pour une raison quelconque.


316
2018-02-06 01:50



"chmod -R 775 fabrikam.com". Très peu de fichiers dans la plupart des sites Web doivent être exécutables; Par exemple, le script php peut être 0640 tant que le serveur Web peut les lire. chmod -R a + X fabrikam.com donnerait des droits exécutables à tout le monde uniquement sur des répertoires.
belle description! - RNA
Notez bien qu'Apache fonctionne en tant qu'utilisateur apache sur les systèmes dérivés de Red Hat. - Michael Hampton♦
C'est excellent, mais il y a une chose que je n'ai pas comprise: je ne comprends pas l'objectif ou l'avantage de la stratégie consistant à faire d'Apache l'utilisateur / le propriétaire d'un répertoire de fichier s'il est déjà propriétaire du groupe. - idiotprogrammer
C'est un excellent post. Voici ma contribution: Les inconvénients de l’utilisation de www-data en tant que propriétaire et de dev-fabrikam en tant que groupe (mentionné dans Vous pouvez avoir votre gâteau et le manger aussi s’applique également (à l’inverse) au scénario proposé dans Maintenu par un utilisateur unique. Dans ce scénario, chaque fois qu'Apache crée un dossier ou un fichier, l'utilisateur n'y aura pas accès. Il est donc nécessaire de transmettre les fichiers à l'utilisateur d'origine. Je n'ai pas mis à jour la réponse car je ne suis pas sûr à 100% de ma déclaration. Je préférerais que les autres le confirment avant de corriger la réponse.


Je me demande pourquoi tant de gens utilisent (ou recommandent) la partie "autre" (o) des droits Linux pour contrôler ce que peut faire Apache (et / ou PHP). En définissant cette partie droite sur autre chose que "0", vous permettez simplement au monde entier de faire quelque chose sur le fichier / répertoire.

Mon approche est la suivante:

  • Je crée deux utilisateurs séparés. Un pour l’accès SSH / SFTP (si nécessaire), qui possédera tous les fichiers, et un pour l’utilisateur PHP FastCGI (l’utilisateur sous lequel le site Web sera exécuté). Appelons ces utilisateurs respectivement bob et bob-www.
  • bob aura tous les droits (rwx sur des dossiers, rw- fichiers), afin qu’il puisse lire et éditer l’ensemble du site.
  • Le processus PHP FastCGI a besoin r-x droits sur les dossiers et r-- droits sur les fichiers, sauf pour des dossiers très spécifiques comme cache/ ou uploads/, où l'autorisation "write" est également nécessaire. Pour donner cette capacité à PHP FastCGI, il fonctionnera comme bob-www, et bob-www sera ajouté à la création automatique bob groupe.
  • Nous nous assurons maintenant que le propriétaire et le groupe de tous les répertoires et fichiers sont bob bob.
  • Quelque chose manque: nous utilisons même FastCGI, mais Apache a toujours besoin d'un accès en lecture pour le contenu statique ou de fichiers .htaccess qu'il essaiera de lire si AllowOverride est réglé sur autre chose que None. Pour éviter d'utiliser le o une partie des droits, j'ajoute la www-data utilisateur à la bob groupe.

À présent:

  • Pour contrôler ce que le développeur peut faire, nous pouvons jouer avec le vous une partie des droits (mais ceci est la note ci-dessous).
  • Pour contrôler ce que Apache et PHP peuvent faire, nous pouvons jouer avec g une partie des droits.
  • le o partie est toujours définie sur 0, de sorte que personne d'autre sur le serveur ne peut lire ou modifier le site Web.
  • Il n'y a pas de problème quand bob l’utilisateur crée de nouveaux fichiers, car il appartiendra automatiquement à son groupe principal (bob).

Ceci est une récapitulation, mais dans cette situation, bob est autorisé à SSH. S'il ne devrait y avoir aucun utilisateur autorisé à modifier le site Web (par exemple, un client ne le modifie que via un panneau d'administration CMS et n'a pas connaissance de Linux), créez quand même deux utilisateurs, mais donnez /bin/falsecomme coquille pour bob aussi bien, et désactiver son login.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Remarque : les gens ont tendance à oublier que la limitation de la vous Les droits (propriétaires) sont la plupart du temps inutiles et peu sûrs, car le propriétaire d’un fichier peut exécuter le fichier. chmod commande, même les droits sont 000.

Dites-moi si mon approche présente des problèmes de sécurité, car je ne suis pas sûr à 100%, mais c'est ce que j'utilise.

Je pense que cette config a un problème: quand PHP / Apache crée un nouveau fichier (par exemple, upload), il appartiendra à bob-www: bob, et bob sera seulement capable de le lire. Peut-être que setuid sur le répertoire peut résoudre le problème.


13
2017-07-19 21:42



Linux ignore setuid. Les nouveaux fichiers appartiennent toujours au créateur. - Paul
Je ne comprends pas quelque chose. Cela ne semble pas inclure la situation où davantage de développeurs travaillent simultanément sur le site Web, car le seul utilisateur est bob. Comment gérez-vous cela? Par exemple. via ssh, les deux utilisateurs se connectent en tant que bob. bob (1) estime qu'il / elle ne se souvient pas du mot de passe et le change en un autre mais reste sécurisé. bob (2) essaie de se connecter la prochaine fois, mais il / elle ne peut pas. - n611x007
@naxa Aucun système marginalement bon ne devrait avoir aucun des développeurs qui modifient directement le site Web. Idéalement, le site Web est sous contrôle de version, de sorte que le compte d'utilisateur 'bob' extrait et déploie automatiquement chaque version (stable). Ainsi, les développeurs effectuent le développement hors site et les modifications sont déployées une fois qu'elles ont été transférées sur le serveur de déploiement. 'bob' est un utilisateur du système qui devrait avoir des autorisations réseau très limitées, qui n'incluent pas la connexion à distance; En fait, iptables vous permet de filtrer par UID pour des choses comme celle-ci. - Parthian Shot
"Je me demande pourquoi tant de gens utilisent (ou recommandent) la" autre "partie (") "- alors peut-être auriez-vous dû poster cela sous forme de question plutôt que de réponse. Il n’est pas rare d’exécuter délibérément le serveur Web (en tant que partie la plus exposée du système) avec le niveau de privilège le plus bas, tandis que les comptes de support, de développement et d’administrateur nécessitent également un accès différent. - symcbean


Étant donné le classement Google sur l'excellente réponse ci-dessus, je pense qu'il y a une chose à noter, et il me semble impossible de laisser une note après la réponse.

Dans l’exemple, si vous envisagez d’utiliser www-data en tant que propriétaire et dev-fabrikam en tant que groupe doté de 570 autorisations sur le répertoire (ou le fichier), il est important de noter que Linux ignore  setuidAinsi, tous les nouveaux fichiers seront la propriété de l'utilisateur qui les a créés. Cela signifie qu'après la création de nouveaux répertoires et fichiers, vous devrez utiliser quelque chose de similaire à:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

Dans Ubuntu 12.04 pour Rackspace OpenStack, j'avais un problème étrange dans lequel je ne pouvais pas obtenir l'autorisation 570 de fonctionner tant que je n'avais pas redémarré le serveur, ce qui a résolu le problème comme par magie. La perte de cheveux à un rythme croissant par rapport à cette question apparemment simple ...


9
2018-01-13 22:03



S'il vous plaît laissez cela être googlé: Dans Raspbian (aka sur un framboise pi, si vous voulez changer la propriété de / var / www sous lighttpd (ou un autre navigateur Web), vous devez redémarrer. - gbronner
@gbronner Si le problème est difficile à résoudre, vous pouvez l'envisager en tant que question et réponse à la question. Cependant, cela est probablement plus approprié sur un autre site de questions-réponses sur la SE. Ma conjecture est Unix et Linux pourrait être un bon endroit pour le faire. - Paul
Il y a aussi raspberrypi.stackexchange.com; il semble que les sites SE fragmentent un peu les connaissances. - gbronner
@gbronner lol. Je ne connaissais pas celui-là! La balise Raspbian sur U & L a quelque chose comme 120 questions. - Paul


Je vais avec cette configuration:

  1. Tous les répertoires, à l'exception du téléchargement d'un ensemble vers le propriétaire root et groupe root, autorisations de 0755.
  2. Tous les fichiers sont définis sur le propriétaire root et groupe root, autorisations de 0644.
  3. Télécharge le répertoire défini sur le propriétaire root, groupe www-data, autorisations de 1770. Le sticky bit ne permet pas au propriétaire du groupe de supprimer ou de renommer le répertoire et les fichiers qu'il contient.
  4. Dans le dossier uploads un nouveau répertoire avec www-data propriétaire utilisateur et groupe, et 0700 autorisations pour chaque www-data utilisateur qui télécharge des fichiers.
  5. Configuration Apache:

Nier AllowOverride et Index dans le répertoire uploads, pour qu'Apache ne lise pas .htaccess fichiers, et l'utilisateur Apache ne peut pas indexer le contenu du dossier uploads:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6 php.ini configuration:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

Avec cette configuration, le www-data l'utilisateur ne pourra pas accéder aux répertoires autres que siteDir/  /tmp et /usr/share/phpmyadmin. Vous pouvez également contrôler la taille de fichier maximale, la taille de publication maximale et le nombre maximal de fichiers à télécharger dans la même demande.


3
2017-10-23 09:54





Lorsque vous avez un utilisateur FTP appelé "leo", vous devez télécharger des fichiers dans le répertoire Web example.com. Vous devez également permettre à votre utilisateur "apache" de créer des fichiers uploa-files / sessions / cache dans le répertoire cache, puis procédez comme suit:

Cette commande assigne leo comme propriétaire et le groupe comme apache à example.com. L'utilisateur apache fait partie du groupe apache et hérite donc des autorisations du groupe apache.

chown -R leo: apache exemple.com

Une autre commande qui assure l’autorisation correcte et répond également aux préoccupations de sécurité.

chmod -R 2774 exemple.com

Ici, le premier numéro 2 concerne le répertoire et assure que chaque nouveau fichier créé sera conservé dans les mêmes autorisations de groupe et de propriétaire. 77 est pour le propriétaire et le groupe signifie qu'ils ont un accès complet. 4 signifie pour les autres qu’ils ne peuvent lire qu’auge.

ce qui suit est utile pour comprendre les numéros de permission

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

3
2017-08-09 07:15