setfsuid(2) System Calls Manual setfsuid(2) NOM setfsuid - Definir l'UID pour les verifications d'acces au systeme de fichiers BIBLIOTHEQUE Bibliotheque C standard (libc, -lc) SYNOPSIS #include [[obsolete]] int setfsuid(uid_t fsuid); DESCRIPTION Sur Linux, un processus a un identifiant utilisateur pour le systeme de fichiers et un identifiant utilisateur effectif. L'identifiant utilisateur du systeme de fichiers (specifique a Linux) est utilise pour valider les droits lors de l'acces aux systemes de fichiers, alors que l'identifiant utilisateur effectif est utilise pour d'autres types de validations de droits (voir credentials(7)). Normalement, la valeur de l'identifiant utilisateur de systeme de fichiers d'un processus est la meme que celle de son identifiant utilisateur effectif. Cela car a chaque fois que l'identifiant utilisateur effectif est modifie, le noyau change l'identifiant de systeme de fichiers pour lui donner la meme valeur que celle du nouvel identifiant d'utilisateur effectif. Un processus peut faire diverger ces deux identifiants en utilisant setfsuid() pour passer son identifiant utilisateur de systeme de fichiers a la valeur donnee dans fsuid. Les appels explicites a setfsuid() et a setfsgid(2) ne sont (n'etaient) normalement utiles qu'aux programmes tels que le serveur NFS qui ont besoin de modifier l'UID et le GID utilise pour les acces aux fichiers sans changer veritablement leurs UID et GID reels et effectifs. Une modification des identifiants normaux d'un programme comme un serveur NFS serait un trou de securite qui l'exposerait a des signaux indesirables (neanmoins ce probleme est historique ; voir ci-dessous). setfsuid() ne reussira que si l'appelant est le superutilisateur ou si fsuid correspond a l'UID reel de l'appelant, a son UID effectif, a son UID sauve, ou encore a la valeur de l'UID au niveau du systeme de fichier au moment de l'appel. VALEUR RENVOYEE En cas de succes comme en cas d'echec, l'appel renvoie la derniere valeur de l'identifiant utilisateur (UID) de l'appelant dans le systeme de fichiers. STANDARDS Linux. HISTORIQUE Linux 1.2. Lorsque cet appel systeme a ete introduit, un processus pouvait envoyer un signal a un autre processus avec le meme identifiant utilisateur effectif. Cela avait pour consequence que si un processus disposant de privileges changeait son identifiant utilisateur effectif afin de valider les droits d'un fichier, il etait susceptible de recevoir des signaux d'un autre processus (ne disposant pas de privileges) avec le meme identifiant utilisateur. Pour cette raison, l'attribut ID utilisateur a ete introduit au niveau du systeme de fichiers pour permettre a un processus de changer son identifiant utilisateur et valider les droits d'un fichier, sans pour autant devenir vulnerable au signaux envoyes par d'autres processus. A partir de Linux 2.0, la prise en charge des permissions des signaux a evolue (consultez kill(2)), de sorte que la modification d'un processus puisse changer l'ID utilisateur effectif sans pour autant rendre le processus vulnerable aux signaux non sollicites envoyes par d'autres processus. Ainsi, setfsuid() n'est desormais plus necessaire et on doit eviter d'y avoir recours dans les nouvelles applications (de meme qu'on evitera d'utiliser setfsgid(2)). L'appel systeme setfsuid() originel de Linux ne gerait que des identifiants d'utilisateur sur 16 bits. En consequence, Linux 2.4 a ajoute setfsuid32() qui prend en charge des identifiants 32 bits. La fonction setfsuid() de la glibc qui l'encapsule gere de maniere transparente ces differences entre noyaux. Differences entre bibliotheque C et noyau Dans la glibc 2.15 et les versions precedentes, lorsque l'enveloppe autour de cet appel systeme determine que l'argument ne peut pas etre passe au noyau sans tronquer un entier (le noyau etant ancien et ne gerant pas les identifiants utilisateur en 32 bits), elle renverra -1 et positionnera errno sur EINVAL sans essayer l'appel systeme. BOGUES Aucune indication concernant l'erreur n'est renvoyee a l'appelant et le fait que la meme valeur soit retournee en cas de succes ou d'echec ne permet pas de savoir si l'appel a reussi ou echoue. Pour cela, l'appelant devra se referer a la valeur renvoyee par un appel ulterieur par exemple a setfsuid(-1) (qui echouera toujours). Cet appel permettra de savoir si un appel anterieur a setfsuid() a change l'identifiant utilisateur au niveau du systeme de fichiers. Au minimum, EPERM doit etre renvoye lorsque l'appel echoue (puisque l'appelant ne dispose pas des privileges CAP_SETUID). VOIR AUSSI kill(2), setfsgid(2), capabilities(7), credentials(7) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot , Cedric Boutillier , Frederic Hantrais et Jean-Philippe MENGUAL Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.06 31 octobre 2023 setfsuid(2)