0
votes

Est-il possible d'exécuter une méthode goroutine ou aller sous un autre utilisateur?

Je travaille sur un petit serveur Web qui sert de fichiers et donne accès au répertoire de base de chaque utilisateur.

Si la source devait être en C, j'ai eu la possibilité de répondre à chaque demande sous différents threads et de vous assurer que chaque thread doit fonctionner avec l'utilisateur de l'appelant comme utilisateurs.

Y a-t-il une approche pour atteindre quelque chose de similaire à celui-là? Idéalement, la partie du code qui gère la demande, la goroutine ou la méthode appelée doit être exécutée sous le compte d'utilisateur de l'appelant.

J'ai fait des recherches et cela semble aller, nous pouvons coller un seul goroutin sur le fil actuel, mais je ne vois pas comment il est possible de créer un nouveau fil puis de fixer une goroutine à ce fil.

go threadpool goroutine

0 commentaires

3 Réponses :

3
votes

Il n'est pas possible d'exécuter un goroutine ou une méthode comme utilisateur différent, car ils fonctionnent tous les deux dans le même contexte que le processus parent. Les gorouts sont équivalents à des fils verts et ne sont même pas nécessairement générés de manière nécessairement un fil d'exploitation approprié par routine.

Cette réponse pourrait également dépendre du système d'exploitation, mais je ne pense pas que cela fonctionnera sur les fenêtres non plus.

Si vous reprochez un autre processus via le package cmd , cette réponse peut être utile. Exécuter des commandes externes via OS / Exec sous un autre utilisateur



                                                                    
                                    
                                    
                                        1 commentaires
                                        
                                                                                            
                                                    Même si un système d'exploitation prend en charge les autorisations de sous-processus, Go n'expose pas cette fonctionnalité. (Je ne suis pas au courant d'un tel système d'exploitation existant)


                        
                                            
                            
                                
                                    2
 votes
                                
                            
                            
                                
                                     Oui, vous pouvez le faire avec l'utilisation du linux syscall  setuid  code> (pas la fonction intégrée  setuid  code>). Je viens de trouver cette question et pensais que cela doit être possible, comme je l'utilise également dans d'autres langages de programmation. J'ai donc eu mon problème résolu et je voulais rappeler comment faire cela. 
 Cependant, c'est correct ce que SJP a écrit sur les threads et il réside exactement la réponse à mon problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème, mais cela ne résoudra pas votre problème. Le problème de threading -  histoire entière dans ce très long numéro 1435 . Il y a aussi une suggestion dans la manière de résoudre un sous-ensemble spécifique du problème  code> setuid  code> et qui a résolu mon problème.  P> 
 mais retour au code ... Vous devez appeler  LOCKOSTHEADADAD  CODE> Pour résoudre la routine actuelle GO sur le thread que vous exécutez actuellement dans et dans cela, vous pouvez modifier le contexte avec le SYSCALL  setuid  code>.  P> 
  P> Voici un exemple de travail pour Linux:  P> 
_, _, serr := syscall.Syscall(syscall.SYS_SETUID, 1, 0, 0)

                                

                                                                    
                                    
                                    
                                        0 commentaires
                                        
                                                                                    
                                    
                                                            
                        
                        
                                            
                            
                                
                                    0
 votes
                                
                            
                            
                                
                                     [Cette réponse est similaire à celle de @ A.Steinel mais, hélas, je suis insuffisant de la réputation de commenter celui-là. Espérons que cela offre un exemple plus complet d'un exemple complet et, surtout, démontre la conservation du temps d'exécution de la confusion de threads en cours d'exécution avec des uids différents.] 
 Premier, pour faire de manière stricte ce que vous avez demandé nécessite un certain nombre de hacks et d'ISN 'T Tout ce qui sécurisé ...  p> 
 [Go aime fonctionner avec  POSIX SEMANTICS  et ce que vous voulez faire est de casser la sémantique de Posix en fonctionnant avec deux ou plusieurs UID en même temps dans un seul processus. Go veut que la sémantique Posix, car elle dirige des goroutines sur tout le fil est disponible et que le temps d'exécution a besoin d'eux pour tous se conduire de même pour que cela fonctionne de manière fiable. Puisque Linux  Setuid ()  Code> Syscall n'honorer pas à Posix Semantics, optez sur  non implémenter syscall.setuid ()  jusqu'à tout récemment quand il est devenu  possible de la mettre en œuvre  avec  em> Posix Semantics en Go1.16 .  P> 

 Remarque,  glibc  code>, si vous appelez  setuid ()  code>, enveloppe la syscall elle-même avec un mécanisme de fixation ( GLIBC / NPTL / SETXID ) et changera les valeurs UID pour tous les threads du programme  simultanément  em>. Donc, même en C, vous devrez faire du piratage pour contourner ce détail.]  Li>
 ul>  qui étant dit, vous pouvez faire fonctionner des gorouts de votre choix avec l'appel  runtime.lockosthread ()  code>, mais ne confondez pas le temps d'exécution de Go en supprimant les fils verrouillés immédiatement après chaque Utilisation spécialisée.  p> 
 quelque chose comme ça (appelez-le  uidserve.go  code>):  p>  xxx  pré> 
 construire comme ceci:  P> 
$ sudo chown root ./uidserve
$ sudo chmod +s ./uidserve

                                

                                                                    
                                    
                                    
                                        0 commentaires