Objectif des autorisations telles que 0111 ou 0333

Quel est le but des autorisations Linux telles que 111 ou 333 (c'est-à-dire que l'utilisateur peut exécuter , mais ne peut pas lire le fichier), si la capacité à exécuter n'implique pas automatiquement la capacité à lire?

permissions chmod

— chariot813
source

Avez-vous un exemple pour un tel paramètre? Je pense que tu as raison. Vous ne pouvez pas exécuter ce que vous ne pouvez pas lire. Ces combinaisons sont juste théoriques dans l'espace des permissions entre 0000 et 0777. Notez que le 0 de tête doit être ajouté pour montrer la base octale du nombre.

— ikrabbe

Sauf s'il s'agit d'un script (par exemple, shell-script), vous n'avez en fait pas besoin d'une autorisation de lecture pour exécuter une commande. Un exécutable "normal" - par exemple. su, bash ou vi - il suffit de définir le bit exécutable pour permettre à un utilisateur de l'exécuter. Un fichier qui ne peut pas être lu, ne peut pas être copié . Donc, en ne permettant pas à un utilisateur de copier une commande importante pour la sécurité (comme su), il est empêché d'en faire sa propre copie - et également d'essayer de la démonter. * BSD a plusieurs commandes avec exécution mais aucune autorisation de lecture.

— Baard Kopperud

Réponses:

J'ai joué avec et apparemment, les autorisations d'exécution n'impliquent pas les autorisations de lecture. Les binaires peuvent être exécutables sans être lisibles:

$ echo 'int main(){ puts("hello world"); }' > hw.c
$ make hw
$ ./hw
hello world
$ chmod 111 hw
$ ./hw 
hello world
$ cat hw
/bin/cat: hw: Permission denied

Cependant, je ne peux pas exécuter de scripts, à moins qu'ils n'aient à la fois des bits d'autorisation de lecture et d'exécution sur:

$ cat > hw.sh
#!/bin/bash
echo hello world from bash
^D
$ chmod +x ./hw.sh
$ ./hw.sh 
hello world from bash
$ chmod 111 ./hw.sh
$ ./hw.sh
/bin/bash: ./hw.sh: Permission denied

— PSkocik
source

C'est correct car le deuxième exemple utilise le #! pour démarrer car il manque l'en-tête ELF et nécessite donc que le fichier soit lisible pour qu'il devine quel exécutable l'utiliser. Il s'agit d'une situation courante pour laquelle vous souhaitez protéger le contenu des fichiers contre la copie vers d'autres emplacements. Un gestionnaire de licence est un exemple courant où vous verriez cela.

— hspaans

Notez que vous pouvez toujours lire un binaire exécutable uniquement: unix.stackexchange.com/a/34294

— 小太郎

@hspaans: Le shebang est géré par le noyau, et le noyau ne se soucie pas des petites choses étranges comme les permissions. C'est le shell (ou interprète) qui a besoin d'un accès en lecture. Le noyau s'exécute (disons) /bin/bash hw.sh, puis bash essaie de s'ouvrir hw.shen lecture (et échoue).

— Kevin

Pour ma part , espère bien que le noyau ne charge sur les autorisations. Rien d'autre ne fait. Ce que la phrase effrayante dans la publication de @ Kevin signifie, c'est que le noyau ne nécessite que des autorisations d'exécution pour exécuter des fichiers, qu'ils utilisent ou non le shebang.

— Emil Jeřábek soutient Monica le

@ EmilJeřábek Le noyau se soucie des autorisations lorsqu'il décide de ce qu'un processus d'application peut faire. Mais comme c'est le composant qui implémente les autorisations, il peut également les ignorer en interne. Ainsi, il peut lire la ligne shebang lors de la détermination de la façon d'exécuter le fichier interprété ou lire le contenu d'un fichier binaire à exécution seule dans la mémoire.

— Barmar

cela a du sens pour les répertoires, par exemple si vous conservez des exécutables (secrets) dans un répertoire spécifique et autorisez ensuite les utilisateurs à appeler ces fichiers sans pouvoir voir le contenu du répertoire (mais en sachant qu'un fichier spécifique est là après que vous les ayez informés!). 333 par rapport à 111 permet d'écrire / supprimer des fichiers vers / depuis ces répertoires sans pouvoir voir le contenu du répertoire.

— Afsin Toparlak
source

À mon Uni, ces autorisations ont été utilisées pour déposer des devoirs dans un répertoire sans que les étudiants voient les autres travailler. Le conférencier était vieux skool.

— DarkHeart

@DarkHeart Intéressant. J'espère que vous avez dû ajouter un composant aléatoire aux noms de fichiers, car sinon, si ce n'est pas une incitation à essayer de copier à partir de vos camarades de classe, je ne sais pas ce que c'est.

— PSkocik

Évidemment, toutes les combinaisons ne sont pas aussi utiles, mais pour prendre celle que vous avez mentionnée spécifiquement ... Vous n'avez en fait pas besoin de readpermission pour exécuter un fichier - seulement une executepermission - sauf si le fichier en question est un script (par exemple un shell-script ( .sh), perl-script ( .pl) et ainsi de suite). Les binaires normaux peuvent être exécutés avec juste l' executeautorisation. Sur * BSD-systmes, plusieurs exécutables donnent une executepermission sans readpermisson, en particulier sur les commandes "importantes pour la sécurité" - par exemple su.

Alors pourquoi ne pas donner aux utilisateurs la readpermission (et juste la executepermission)? Devenir un fichier qui ne peut pas être lu par un utilisateur, ne peut pas non plus être copié par cet utilisateur! La suppression de l' readautorisation empêche les utilisateurs de créer leurs propres copies «personnelles» d'exécutables - qu'ils pourront plus tard abuser (par exemple obtenir SUID=root on).

Et ne pas avoir write-permission, empêche un fichier d'être supprimé par conséquent.

Rappelez - vous, ne pas donner ni read-NOR write-Permission au propriétaire est un rare bits, mais parfois il peut être une bonne idée d'éviter même le ownerde simplement la suppression d' un fichier. Bien sûr, le owner- pour ne pas mentionner root- peut toujours contourner de telles mesures, sinon par d'autres moyens, simplement par chmodl'autorisation sur le dossier.

— Baard Kopperud
source

"ce peut être une bonne idée d'empêcher même le ownerjuste de supprimer un fichier." - sauf que vous n'avez besoin d'aucune autorisation sur un fichier (lecture, écriture ou exécution) pour le supprimer.

— Celada

Les exécutables prêts à l'emploi peuvent être utilisés par exemple si l'exécutable incorpore un mot de passe de base de données qu'il utilise lors de son exécution pour se connecter à une base de données et faire son travail, mais il ne veut pas nécessairement révéler le mot de passe.

— Celada

@Celada, c'est une vieille question, mais une telle approche ne serait-elle pas susceptible de vider la mémoire en recherchant les décalages de la région de mémoire /proc/${PID}/mapspuis en lisant les sections pertinentes de la mémoire /proc/${PID}/mem? Ou la restriction des autorisations sur le fichier de l'exécutable restreint-elle également les autorisations de lecture sur ses sections pertinentes en mémoire pendant l'exécution? (Ce dernier semble peu probable, OMI.)

— Spencer D