Modifier l’autorisation de fichier dans C manuellement

… Je veux implémenter mon propre chmod en C … pour apprendre ce qui se passe dans le back-end …

La bibliothèque C encapsule les parties dépendantes du système de ces fonctions.

Si vous voulez savoir ce qui se passe dans la bibliothèque C et au-delà, vous devez savoir comment votre système particulier appelle le kernel – pour Linux x86, il s’agit par exemple de l’instruction INT 0x80 . Voir par exemple https://en.wikipedia.org/wiki/System_call pour commencer.

Pour apprendre comment chacune des fonctions C fonctionne en interne, je vous suggère de récupérer les sources de la bibliothèque GNU C et de les étudier: Voir http://sourceware.org/git/?p=glibc.git

Libc vous offre une façon indépendante de faire des appels système avec une architecture cpu. Ce que fait chmod ou tout autre appel syscall est de déplacer vos arguments d’appel de fonction vers les bons registres ou au bon endroit de la stack, plus une valeur spéciale indiquant quel appel système est appelé (pour chmod sous Linux, 90, 15) puis utilisez les instructions ou séquences d’instructions nécessaires pour que le kernel prenne le relais et exécute l’appel système. Lorsque le kernel revient à l’utilisateur, il a le moyen de renvoyer une erreur à l’utilisateur. Si l’erreur n’était pas 0, l’encapsuleur syscall libc le place dans la variable errno globale et renvoie une erreur. Sur la plupart des appels système, le retour d’erreur est -1, de sorte que le programmeur libc peut être paresseux et utiliser le même wrapper pour tous les appels système au lieu d’en écrire un pour chaque appel syscall. .

Si vous voulez approfondir le kernel, cela devient plus compliqué. Le CPU, lorsqu’il voit l’instruction syscall, définit son contexte en mode kernel, ce qui inclut la modification du pointeur de la stack et de nombreux autres registres, et passe au code précédemment configuré pour gérer les appels système (architecture du cpu et dépend du système d’exploitation). Il commence généralement par un gestionnaire générique de syscall qui vérifie si le numéro de syscall est valide, déplace les arguments à partir de l’endroit où le processeur a pensé qu’il serait intéressant de les placer à un endroit où le kernel pense qu’ils devraient l’être. d’appeler pour gérer cet appel système particulier et l’appelle. Lorsque cette fonction retourne, elle retourne généralement un code d’erreur que le gestionnaire générique syscall doit renvoyer à l’utilisateur.

Plus bas La fonction particulière qui implémente l’appel système chmod vérifie d’abord les arguments (que le mode est sain) et fait ensuite deux choses. D’abord, il appelle une fonction très complexe qui traduit le nom du fichier en un object interne représentant le fichier qui nous intéresse (ou plutôt un object associé au nom du fichier, car chmod est une opération au niveau du nom et non un object). opération de niveau fichier, histoire longue). Cet object est appelé quelque chose de différent dans différents systèmes d’exploitation, les noms communs sont “inode” ou “vnode”. Cet object a une sorte de structure qui lui est attachée avec des pointeurs de fonctions sur de nombreuses opérations différentes pouvant être effectuées sur cet object. Ceci est fait pour que le kernel puisse prendre en charge de nombreux systèmes de fichiers différents. C’est une approche orientée object. L’une de ces fonctions s’appelle setattr (même si les systèmes d’exploitation sont libres de nommer les choses comme ils le veulent, setattr est couramment utilisé car tout le monde se vole, l’opération NFS s’appelle SETATTR). La fonction syscall de chmod configure des arguments pour que setattr lui dise de modifier les permissions sur le fichier appelle le setattr spécifique au système de fichiers, prend en charge le retour d’erreur et le renvoie au gestionnaire syscall générique.

(Je pourrais approfondir la façon dont la traduction entre un nom de fichier et un object nœud est effectuée, mais je ne le ferai pas. Ce sujet est suffisamment complexe pour remplir un livre.)

Plus bas Le setattr spécifique au système de fichiers setattr généralement une copie en mémoire de l’object du système de fichiers à partir du disque, le marque comme étant sale et le place dans une queue pour être écrit sur le disque ultérieurement. Si votre système de fichiers applique une sorte de mode synchrone pour les changements d’atsortingbuts (cela rend les systèmes de fichiers très, très lents), piquez le graveur sur votre disque dès que possible et attendez qu’il se termine. Cependant, vous espérez généralement que tout ce qui est écrit sur le disque arrive à un moment donné et que vos permissions modifiées soient écrites. C’est pourquoi vous pouvez perdre les modifications du système de fichiers lorsque le système plante ou perd de la puissance. Notez que cela n’a pas d’importance si les choses ont été écrites sur le disque ou non puisque tout le monde qui utilise le système de fichiers travaille à travers le même kernel et les mêmes fonctions et les mêmes copies en mémoire des objects du système de fichiers. Ceci conclut le travail de setattr qui retourne ensuite un code d’erreur au gestionnaire syscall de chmod .