Pourquoi ai-je besoin d'un bit "execute" en mode fichier sur les systèmes de fichiers Unix ?

Parce que *nix n'a pas le cerveau assez dérangé pour faire d'un fichier un "exécutable binaire" si vous le nommez ".exe" ou un "script exécutable" si vous le nommez ".bat".

Sous Linux, le nom du fichier n'a pas d'importance.

Et les permissions que vous donnez à un fichier hacer matière.

Ce qui est assez logique. IMHO...

Le bit execute est quelque peu confus entre être une permission et un identifiant de type d'objet.

Et, non, vous ne pouvez pas "toujours copier" le fichier dans votre répertoire personnel : seulement s'il est lisible pour vous.

Les fichiers peuvent être exécutables pour vous, mais pas lisibles.

Vous avez raison de dire que si vous pouvez lire un fichier mais que vous ne pouvez pas l'exécuter, vous pouvez le copier, inverser le bit execute et l'utiliser. Peut-être. Mais cela peut ne pas fonctionner. L'exécutable peut être sensible à l'endroit où il est installé. Ou le fichier peut dépendre de son bit setuid root.

Je ne concevrais pas un système d'autorisation de cette façon en partant d'une page blanche ; cela n'a pas tout à fait de sens. L'autorisation d'exécution serait distincte d'un attribut de type exécutable, et l'autorisation d'exécution ne serait pas surchargée avec l'autorisation de recherche (même si elle était stockée de cette façon ; l'API ne la révélerait pas au niveau du masque de bits).

C'est un bon point, et je pense que je vois où vous voulez en venir.

Pour réinterpréter votre question : L'affirmation suivante est-elle vraie - "Le fait de mettre un exécutable en mode non exécutable pour un utilisateur ne limite pas les capacités de ce dernier".

Je pense que c'est vrai.

1. Copiez le fichier dans un autre répertoire.
2. Changez les perms.
3. Exécuter à partir de n'importe quel pwd (en particulier, le répertoire d'origine) en donnant le chemin complet de la nouvelle copie de l'exécutable, avec des arguments de ligne de commande.

Je ne pense pas qu'il manque quoi que ce soit d'autre, que vous auriez en ayant l'exec perm du fichier original activé.

Par pwd, j'entends le répertoire de travail actuel.

Il existe de nombreuses raisons pour lesquelles vous pouvez souhaiter marquer un fichier comme lisible mais non exécutable, notamment par certains utilisateurs ou groupes. Considérez les cas suivants :

# /usr/local/sbin/foo.sh
-rwxr--r-- 1 root root 890 2012-02-17 21:09 /usr/local/sbin/foo.sh

# ~/bin/foo.sh
-rwxr-xr-x 1 user user 890 2012-02-17 21:09 /home/bin/foo.sh

Cela pourrait avoir un sens si :

1. Les fichiers sont différents - peut-être avez-vous remplacé chaque instance de "root" par "user" dans le script - mais votre chemin contient /usr/local/sbin:/home/user/bin . Les autorisations permettront de s'assurer que l'exécution foo.sh exécutera la copie modifiée de l'utilisateur, même si la copie de root viendrait en premier dans le chemin de recherche si son bit execute était activé.
2. Les fichiers sont identiques, mais font quelque chose de différent au moment de l'exécution en fonction de leur nom de base, du répertoire parent, du répertoire personnel de l'utilisateur appelant ou d'une autre astuce de programmation. Dans de tels cas, il faut veulent les utilisateurs doivent copier le fichier ailleurs avant de l'exécuter. Beaucoup d'exemples de scripts suppriment le bit execute afin de forcer les utilisateurs à copier et personnaliser.

Finalement, rien ne vous empêche de copier n'importe quel fichier que vous pouvez lire, ou même de l'exécuter directement avec sh /path/to/file . Le bit d'exécution manquant pour votre utilisateur ou groupe vous empêche juste de le faire en accident . Ce n'est pas une mesure de sécurité, et il ne faut pas la prendre pour telle.