CHMOD(2) | Manuel du programmeur Linux | CHMOD(2) |
chmod, fchmod, fchmodat - Modifier les permissions d'accès à un fichier
#include <sys/stat.h>
int chmod(const char *pathname, mode_t mode); int fchmod(int fd, mode_t mode); #include <fcntl.h> /* Définition des constantes AT_* */ #include <sys/stat.h>
int fchmodat(int dirfd, const char *pathname, mode_t mode, int flags);
fchmod() :
Glibc 2.19 à 2.23
_POSIX_C_SOURCE
De Glibc 2.16 à 2.19 :
_BSD_SOURCE || _POSIX_C_SOURCE
De Glibc 2.12 à 2.16 :
_BSD_SOURCE || _XOPEN_SOURCE >= 500 ||
_POSIX_C_SOURCE >= 200809L
Glibc 2.11 et antérieures :
_BSD_SOURCE || _XOPEN_SOURCE >= 500
fchmodat() :
Les appels système chmod() et fchmod() modifient les bits du mode d'un fichier (le mode d'un fichier consiste dans les bits des droits du fichier et les bits set-user-ID, set-groupe-ID et sticky). Ces appels système ne diffèrent que dans la manière dont les fichiers sont indiqués :
Le nouveau mode du fichier est indiqué dans mode, qui est un masque de bit créé par un OU bit à bit de zéro ou plusieurs des valeurs suivantes :
L'UID effectif du processus appelant doit correspondre à celui du propriétaire du fichier, ou le processus doit être privilégié (sous Linux : il doit avoir la capacité CAP_FOWNER).
Si le processus appelant n'est pas privilégié (sous Linux : n'a pas la capacité CAP_FSETID), et si le groupe du fichier ne correspond ni au GID effectif du processus, ni à l'un de ses éventuels groupes supplémentaires, le bit S_ISGID sera désactivé, mais cela ne créera pas d'erreur.
Par mesure de sécurité, suivant le type de système de fichiers, les bits Set-UID et Set-GID peuvent être effacés si un fichier est écrit. (Sous Linux, cela arrive si le processus qui écrit n'a pas la capacité CAP_FSETID. Sur certains systèmes de fichiers, seul le superutilisateur peut positionner le Sticky-Bit, lequel peut avoir une signification spécifique. Pour la signification du Sticky-Bit et du bit Set-GID sur les répertoires, consultez inode(7).
Sur les systèmes de fichiers NFS, une restriction des autorisations d'accès aura un effet immédiat y compris sur les fichiers déjà ouverts, car les contrôles d'accès sont effectués sur le serveur, mais les fichiers sont maintenus ouverts sur le client. Par contre, un élargissement des autorisations peut ne pas être immédiat pour les autres clients, s'ils disposent d'un cache.
L'appel système fchmodat() fonctionne exactement comme chmod(2), les seules différences étant celles décrites ici.
Si pathname est un chemin relatif, il est interprété par rapport au répertoire référencé par le descripteur de fichier dirfd, plutôt que par rapport au répertoire courant, comme dans chmod().
Si pathname est un chemin relatif, et si dirfd est la valeur spéciale AT_FDCWD, pathname est interprété comme étant relatif au répertoire courant du processus appelant, comme pour chmod().
Si pathname est absolu, alors dirfd est ignoré.
L'argument flags est soit 0, soit un OU binaire « | » avec les options suivantes :
Consultez openat(2) pour une explication de la nécessité de fchmodat().
En cas de succès, zéro est renvoyé. En cas d'erreur, -1 est renvoyé et errno reçoit une valeur adéquate.
Suivant le type de système de fichiers, d'autres erreurs que celles listées ci-desous peuvent être renvoyées.
Les erreurs les plus courantes pour chmod() sont :
Les erreurs les plus courantes pour fchmod() sont :
Les mêmes erreurs qui apparaissent pour chmod(2) peuvent apparaître pour fchmodat(). Les erreurs supplémentaires suivantes peuvent également se produire pour fchmodat() :
fchmodat() a été ajouté au noyau Linux dans sa version 2.6.16 ; la glibc le gère depuis la version 2.4.
chmod(), fchmod() : 4.4BSD, SVr4, POSIX.1-2001i, POSIX.1-2008.
fchmodat() : POSIX.1-2008.
La fonction enveloppe fchmodat() de la bibliothèque C de GNU implémente l'interface conforme à POSIX décrite dans cette page. Cette interface est différente de l'appel système Linux sous-jacent, qui n'a pas d'argument flags.
Sur les anciens noyaux où fchmodat() n'est pas disponible, la fonction enveloppe de glibc se rabat sur l'utilisation de chmod(). Quand chemin est relatif, glibc construit un chemin à partir du lien symbolique dans /proc/self/fd et qui correspond au paramètre dirfd.
chmod(1), chown(2), execve(2), open(2), stat(2), inode(7), symlink(7)
Cette page fait partie de la publication 5.10 du projet man-pages Linux. Une description du projet et des instructions pour signaler des anomalies et la dernière version de cette page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.
La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot <david@tilapin.org> et Jean-Philippe MENGUAL <jpmengual@debian.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.
15 septembre 2017 | Linux |