Définition des autorisations d'accès sur Sémaphore?

Question

Je suppose qu'une fois sémaphores est créé par un processus, il sera accessible par tout processus / utilisateur.

Est-il possible de mettre des restrictions d'accès sur un sémaphores particulier afin qu'il puisse être accessible que par certains processus / utilisateurs ou que certains processus peuvent libérer le sémaphores.
Je vois quelques problèmes si nous faisons un sémaphores accessible par tous processes.Eg: un processus factice peut lire le sémaphores et libérer le verrou à souhait faire un faux signal au processus réel qui attend vraiment la serrure sémaphores

.

Toutes ces questions se posent que je reçois de sortie très bizarre avec l'extrait de code suivant:

use Win32::Semaphore; 

$sem = Win32::Semaphore->new(0, 1,"reliance2692") 
    or print "Can't create semaphore\n";

$sem = Win32::Semaphore->open("reliance2692") 
    or print "Can't open semaphore\n";

print "Semaphore:" . $sem . "\n";

En exécutant le programme ci-dessus, je reçois la sortie suivante

Can't create semaphore
Can't open semaphore

La sortie montre que son échec à créer un sémaphores et même échoué à ouvrir sémaphores. la création d'un sémaphores aurait échoué si un sémaphores existe déjà avec le nom donné. Je ne comprends pas pourquoi l'ouverture d'un sémaphores a échoué.

Quelqu'un peut clarifier le scénario où à la fois la création échoue sémaphores sémaphores et ouverture.

Answer 1

De Win32 :: Sémaphore pod

$semaphore = Win32::Semaphore->new($initial, $maximum, [$name])

  

Constructor pour un nouvel objet de sémaphores. $ Initiale est le nombre initial, et $ maximum est   le nombre maximum pour la sémaphores. Si le nom $ est omis ou FNUD, crée un sans nom   objet sémaphore.

     

Si le nom $ signifie un objet sémaphores existant, sont ignorés initiale et maximale de $ $   et l'objet est ouvert. Dans ce cas, $^E sera réglé sur 183   (ERROR_ALREADY_EXISTS).

Si je lis correctement, si votre appel à Win32::Semaphore->new fait référence à un sémaphore existant, l'appel new ouvrira la sémaphores ainsi, et l'appel open ultérieur sera redondant (ce n'est pas clair pour moi du pod ce qui devrait se produire si vous ouvrez un sémaphore qui est déjà ouvert).

Peut-être que vous pourriez parcourir le code, la vérification de la valeur de $sem ainsi que $! et $^E à chaque étape.

Réponse complémentaire: API windows a des méthodes pour le réglage de contrôle d'accès des sémaphores, mais

1. ils ne semblent pas être exposés dans le module Perl Win32::Semaphore
contrôle d'accès
2. ne peut pas être que si elle était déjà autorisée par l'autre processus qui a créé le sémaphores

Je ne sais pas si vous avez des bonnes options pour ce problème. Pouvez-vous modifier le processus qui crée le sémaphores pour assouplir les restrictions d'accès? Demandez à l'auteur de Win32::Semaphore mettre à jour son module? Essayez de fixer vous Win32::Semaphore?

Answer 2

Win32::Semaphore->new appelle la fonction API Windows CreateSemaphore et obtient le processus de descripteur de sécurité par défaut , ce qui signifie généralement que les processus en cours d'exécution avec le même utilisateur que votre script peut avoir un accès complet alors que les processus en cours d'autres comptes seront pas accès. Alors, pour commencer, votre hypothèse est fausse.

Le nom que vous choisissez dans votre code Perl est passé directement à la fonction de l'API, il est donc soumis au même règles d'espace de noms comme tous les autres objets du noyau Win32.

Win32 :: Sémaphore ne fournit aucune interface pour les restrictions d'accès. Même si elle l'a fait, Windows ne fournit pas les autorisations par processus. Les autorisations sont attachés à la utilisateur , pas le processus .

Si vous obtenez « accès refusé » de new, puis qui suggère qu'il ya un autre programme en cours qui a choisi d'utiliser le même nom pour quelque chose d'autre - peut-être une autre sémaphores, ou peut-être quelque chose d'autre, comme un événement ou un mutex - et ce processus est exécuté en tant qu'un autre utilisateur.

Si vous obtenez « accès refusé » de open, puis, en plus des possibilités de new, il pourrait être qu'un autre processus a déjà ouvert un sémaphore avec le même nom, mais n'a pas accordé les autorisations à d'autres utilisateurs. demandes de Win32::Semaphore->open SEMAPHORE_ALL_ACCESS autorisation .

Si le sémaphore a déjà été ouverte par un processus en cours d'exécution avec le même utilisateur, alors vous ne devriez pas avoir « accès refusé ». Ni new ni open devraient échouer dans ce cas, bien que $^E peut contenir 183 (ERROR_ALREADY_EXISTS) de toute façon.

Answer 3

Pour mémoire, je suis l'auteur de Win32 :: Sémaphore . Comme mobrule et Rob ont expliqué, la sécurité Windows est basé utilisateur / groupe. Il est impossible d'avoir un sémaphores qui ne peuvent accéder qu'à certains processus. Si un processus appartenant à un utilisateur peut accéder à un sémaphores, puis any processus de cet utilisateur peut accéder à ce sémaphores.

Normalement, l'accès par défaut permet uniquement l'utilisateur actuel pour accéder au sémaphores. Personne n'a jamais demandé la possibilité d'avoir de spécifier Win32 Sémaphore un descripteur de sécurité par défaut, et l'API associée est non négligeable. Si quelqu'un a créé un module pour gérer une structure SECURITY_ATTRIBUTES, je serais heureux d'ajouter le support pour ce à Win32 :: Sémaphore et les modules IPC connexes. Win32-sécurité ne semble pas être ce module, bien qu'il puisse être un début .

Si vous avez besoin d'un sémaphores pour travailler sur plusieurs utilisateurs, votre seule solution droit est maintenant de créer l'sémaphores en dehors de Win32 :: Sémaphore, le passage d'un pointeur SECURITY_ATTRIBUTES approprié. Vous pouvez le faire avec un petit programme d'aide écrit en C ou en utilisant Inline :: C . (Rappelez-vous qu'une fois créé, un sémaphores existe aussi longtemps que tout processus a une poignée ouverte à elle, de sorte que votre programme d'aide doit garder la poignée de sémaphores ouverte jusqu'à ce que vous avez appelé Win32::Semaphore->open là-dessus.)