Accès en écriture sans accès en lecture

Est-il possible pour un utilisateur d'avoir un accès en écriture à un fichier et de ne pas pouvoir le lire? Comment est-ce possible?

J'ai essayé les commandes suivantes:

debianbox@debian:~/posix/io$ touch filetest
debianbox@debian:~/posix/io$ ls -l filetest
-rw-r--r-- 1 debianbox debianbox 0 14 oct.  03:10 filetest

debianbox@debian:~/posix/io$ echo "Hello World" > filetest
debianbox@debian:~/posix/io$ cat filetest
Hello World

debianbox@debian:~/posix/io$ chmod u-r filetest
debianbox@debian:~/posix/io$ cat filetest
cat: filetest: Permission forbidden

debianbox@debian:~/posix/io$

Comme vous pouvez le voir ici, j'ai un accès en écriture mais pas en lecture sur ce fichier. Comment cela est-il possible? Est-ce considéré comme un bug? Sinon, dans quelle situation cela serait-il utile?

Ce n'est pas un bug, c'est une fonctionnalité ^TM (aussi, juste une conséquence de l'approche universelle d'Unix pour les autorisations).

Mis à part le comportement de type dropbox dans le cas des répertoires (comme décrit par BillThor), un accès en écriture seule est nécessaire pour certains fichiers (pseudo-) spéciaux sous /procet /sys. Ces fichiers sont utilisés pour définir certaines propriétés du pilote ou du noyau ou déclencher une action système. Vous ne pouvez pas les lire, car ils ne sont utilisés que pour la signalisation unidirectionnelle - vous ne pouvez leur faire écho que du texte / des données. Pour trouver de tels fichiers, vous pouvez utiliser

find /proc/[^0-9]* /sys -perm /222 ! -perm /444

Notez que, puisque ces fichiers sont utilisés pour la configuration avancée du système (potentiellement dangereux), il n'y roota qu'un accès en écriture (dans la plupart des cas).

La principale raison d'autoriser l'accès en écriture sans accès en lecture est qu'il simplifie la gestion des autorisations, à la fois à l'intérieur du noyau et dans les programmes utilisateur. Il existe deux autorisations, l'une pour la lecture et l'autre pour l'écriture, et elles sont gérées indépendamment. Ce n'est pas un bogue car le comportement documenté coïncide avec le comportement réel et il n'y a aucune bonne raison d'exiger un comportement différent.

Avoir des autorisations d'écriture sans autorisations de lecture n'a pas beaucoup de sens pour les fichiers normaux. Cela a du sens pour divers fichiers spéciaux.

• Certains systèmes autorisent les fichiers à ajouter uniquement. C'est utile pour les fichiers journaux, par exemple. Il peut être judicieux d'autoriser de nombreux utilisateurs à créer des entrées de journal, mais pas de leur permettre d'effacer ou d'écraser des entrées existantes (d'où: autorisation d'écriture, mais attribut à ajouter uniquement), ni de leur permettre de lire les entrées des autres (d'où: non autorisation de lecture).
• Un programme peut être autorisé à écrire dans un canal nommé sans être autorisé à le lire.
• Certains appareils sont en écriture seule. Par exemple, un périphérique de sortie audio connecté à un haut-parleur mais sans microphone doit avoir une autorisation d'écriture mais pas de lecture.
• Il existe différents systèmes de fichiers spéciaux où la lecture ou l'écriture dans un fichier a un effet immédiat au lieu de récupérer ou d'ajouter des données au stockage. Par exemple, sous Linux, il existe divers fichiers sous /procet /sysqui permettent aux programmes de l'espace utilisateur d'envoyer des commandes au noyau en écrivant dans un fichier particulier. Si cette commande ne fournit aucun retour, le fichier spécial est rendu en écriture seule.

Non ce n'est pas un bug. Cependant, je ne le vois pas couramment appliqué aux fichiers.

J'ai le plus souvent vu un accès en écriture uniquement sur les répertoires de la boîte de dépôt. Les utilisateurs peuvent ajouter des fichiers au répertoire, mais ne peuvent pas voir quels fichiers existent.

Pour un fichier texte normal, un accès en écriture uniquement serait approprié pour un accès de type dropbox.

Définir un accès en écriture uniquement pour vous-même ne serait pas très utile, mais ne pas l'autoriser compliquerait le code des autorisations.

EDIT: les fichiers Dropbox ne sont probablement pas utiles. Cependant, il peut être utile pour les journaux non root, car il serait plus difficile d'écraser les entrées de journal. Si vous pouvez lire le fichier, il est beaucoup plus facile d'identifier où écrire une entrée de journal de remplacement. Cependant, je ne connais personne qui configure ses journaux comme celui-ci. Il est courant d'utiliser la journalisation à distance pour empêcher la modification locale des entrées de journal.

La définition de règles sur lesquelles les combinaisons d'autorisations sont autorisées peut conduire à empêcher des autorisations utiles imprévues. De nombreuses combinaisons ont plus de sens au niveau du groupe ou du monde qu'au niveau du propriétaire. Toute tentative d'empêcher l'accès par le propriétaire peut être facilement annulée. Cependant, ils peuvent être utiles pour forcer une seconde sobre.