WSCSetApplicationCategory, fonction (ws2spi.h)

Article
08/28/2023

**Remarque** Les fournisseurs de services en couches sont déconseillés. À compter de Windows 8 et Windows Server 2012, utilisez la plateforme de filtrage Windows.

La fonction **WSCSetApplicationCategory** définit les catégories de fournisseurs de services en couche (LSP) autorisées associées à une application.

Syntaxe

int WSCSetApplicationCategory(
  [in]  LPCWSTR Path,
  [in]  DWORD   PathLength,
  [in]  LPCWSTR Extra,
  [in]  DWORD   ExtraLength,
  [in]  DWORD   PermittedLspCategories,
  [out] DWORD   *pPrevPermLspCat,
  [out] LPINT   lpErrno
);

Paramètres

[in] Path

Pointeur vers une chaîne Unicode qui contient le chemin de chargement de l’image exécutable pour l’application. Cette chaîne respecte les règles habituelles de résolution de chemin d’accès et peut contenir des chaînes d’environnement incorporées (telles que %SystemRoot%).

[in] PathLength

Longueur, en caractères, du paramètre Path . Cette longueur n’inclut pas la valeur NULL de fin.

[in] Extra

Pointeur vers une chaîne Unicode qui représente les arguments de ligne de commande utilisés lors du démarrage de l’application spécifiée dans le paramètre Path . Le paramètre Extra permet de distinguer plusieurs instances distinctes d’une application lorsqu’elle est lancée avec une ligne de commande cohérente. Il s’agit de prendre en charge différentes catégorisations d’applications pour différentes instances de Svchost.exe ou de Rundll32.exe. Si seul le paramètre Path est requis et qu’aucun argument de ligne de commande n’est nécessaire pour faire la distinction entre les instances d’une application, le paramètre Extra doit être défini sur NULL.

[in] ExtraLength

Longueur, en caractères, du paramètre Extra . Cette longueur n’inclut pas la valeur NULL de fin.

[in] PermittedLspCategories

Valeur DWORD des catégories LSP autorisées pour toutes les instances de cette application. L’application est identifiée par la combinaison des valeurs des paramètres Path et Extra .

[out] pPrevPermLspCat

Pointeur pour recevoir l’ensemble précédent de catégories LSP autorisées qui étaient autorisées pour toutes les instances de cette application. Ce paramètre est facultatif peut être NULL.

[out] lpErrno

Pointeur vers le code d’erreur en cas d’échec de la fonction.

Valeur retournée

Si aucune erreur ne se produit, WSCSetApplicationCategory retourne ERROR_SUCCESS (zéro). Sinon, elle retourne SOCKET_ERROR et un code d’erreur spécifique est retourné dans le paramètre lpErrno .

Code d'erreur	Signification
WSAEFAULT	Un ou plusieurs arguments ne se trouve pas dans une partie valide de l’espace d’adressage utilisateur.
WSAEINVAL	Un ou plusieurs arguments ne sont pas valides.
WSANO_RECOVERY	Une erreur non récupérable s’est produite. Cette erreur est retournée dans plusieurs conditions, notamment : l’utilisateur n’a pas les privilèges d’administration requis pour accéder au registre Winsock ou un échec s’est produit lors de l’ouverture d’une entrée de catalogue Winsock ou d’une entrée d’ID d’application.

Remarques

WSCSetApplicationCategory est utilisé pour définir les indicateurs de catégorie LSP associés à une application instance. Les applications peuvent déterminer quels comportements LSP sont acceptables dans le contexte de l’application. Par conséquent, en spécifiant des catégories LSP autorisées, une application peut autoriser uniquement les fournisseurs de services en couche qui implémentent des comportements acceptables à être chargés.

Le paramètre Extra est requis lorsque la ligne de commande est utilisée pour faire la distinction entre différentes instances d’une application ou d’un service hébergé dans le même fichier exécutable. Chaque instance peut avoir des besoins de catégorisation d’application différents. Svchost.exe et Rundll32.exe sont deux exemples où la ligne de commande est nécessaire pour différencier les différentes instances de processus. Par SvcHost.exe, le commutateur -k <svcinstance> définit le processus instance.

Pour les services, l’utilisation du nom du service n’est pas suffisante, car le catalogue Winsock est global pour un processus donné et un processus peut héberger plusieurs services.

Si la fonction WSCSetApplicationCategory est appelée sur la même application (le même fullpath, le même nom EXE et les mêmes paramètres) plusieurs fois, les catégories sont ORed ensemble. Par exemple, si vous avez catégorisé « c:\foo.exe -param » avec LSP_SYSTEM, puis que vous avez appelé à nouveau la fonction WSCSetApplicationCategory avec LSP_REDIRECTOR, l’entrée résultante pour cette application contient LSP_SYSTEM | LSP_REDIRECTOR. Ce comportement est conçu pour prendre en charge un fichier exécutable unique qui héberge plusieurs applications dans un seul EXE (les services système Windows svchost.exe, par exemple).

Les sockets de fenêtre déterminent l’identité d’une application et récupèrent les catégories LSP autorisées lors du premier appel à WSAStartup. Il s’agit de l’ensemble des catégories LSP autorisées pendant la durée de l’application instance. Les modifications ultérieures apportées aux catégories LSP autorisées pour une identité d’application donnée ne seront pas récupérées avant la instance suivante de l’application. Les catégories LSP autorisées ne sont pas mutables pendant la durée de vie de l’application instance.

Winsock 2 prend en charge les protocoles en couches. Un protocole en couches est un protocole qui implémente uniquement des fonctions de communication de niveau supérieur, tout en s’appuyant sur une pile de transport sous-jacente pour l’échange réel de données avec un point de terminaison distant. Un exemple de protocole en couches ou de fournisseur de services en couches serait une couche de sécurité qui ajoute un protocole au processus d’établissement de la connexion afin d’effectuer l’authentification et d’établir un schéma de chiffrement mutuellement convenu. Un tel protocole de sécurité nécessite généralement les services d’un protocole de transport fiable sous-jacent, tel que TCP ou SPX. Le terme protocole de base fait référence à un protocole tel que TCP ou SPX qui est capable d’effectuer des communications de données avec un point de terminaison distant. Le terme protocole en couches est utilisé pour décrire un protocole qui ne peut pas être autonome.

Pendant l’initialisation LSP, le LSP doit fournir des pointeurs vers un certain nombre de fonctions Winsock SPI. Ces fonctions seront appelées pendant le traitement normal par la couche située directement au-dessus du LSP (soit un autre LSP, soit un autre Ws2_32.dll).

Un fournisseur de services LSP qui implémente un système de fichiers installable (IFS) peut choisir de manière sélective de fournir des pointeurs vers des fonctions implémentées par elle-même, ou de renvoyer les pointeurs fournis par la couche juste sous le LSP. Les fournisseurs de services de sécurité non-IFS, car ils fournissent leurs propres handles, doivent implémenter toutes les fonctions Winsock SPI. Cela est dû au fait que chaque SPI nécessite que le fournisseur LSP mappe tous les handles de socket qu’il a créés au handle de socket du fournisseur inférieur (soit un autre LSP, soit le protocole de base).

Toutefois, tous les fournisseurs LSP effectuent leur travail spécifique en effectuant un traitement supplémentaire sur un sous-ensemble des fonctions SPI winsock.

Il est possible de définir des catégories LSP en fonction du sous-ensemble de fonctions SPI qu’un LSP implémente et de la nature du traitement supplémentaire effectué pour chacune de ces fonctions.

En classant les LSP, ainsi que les applications qui utilisent des sockets Winsock, il devient possible de déterminer de manière sélective si un LSP doit être impliqué dans un processus donné au moment de l’exécution.

Sur Windows Vista et versions ultérieures, un LSP peut être classé en fonction de la façon dont il interagit avec les appels et les données Windows Sockets. Une catégorie LSP est un groupe identifiable de comportements sur un sous-ensemble de fonctions SPI Winsock. Par exemple, un filtre de contenu HTTP est classé comme inspecteur de données (catégorie LSP_INSPECTOR ). La catégorie LSP_INSPECTOR inspecte (mais ne modifie pas) les paramètres pour les fonctions SPI de transfert de données. Une application peut interroger la catégorie d’un LSP et choisir de ne pas charger le LSP en fonction de la catégorie LSP et de l’ensemble de catégories LSP autorisées de l’application.

Le tableau suivant répertorie les catégories dans lesquelles un LSP peut être classé.

Catégorie LSP	Description
LSP_CRYPTO_COMPRESS	Le LSP est un fournisseur de chiffrement ou de compression de données.
LSP_FIREWALL	Le LSP est un fournisseur de pare-feu.
LSP_LOCAL_CACHE	Le LSP est un fournisseur de cache local.
LSP_INBOUND_MODIFY	Le LSP modifie les données entrantes.
LSP_INSPECTOR	Le LSP inspecte ou filtre les données.
LSP_OUTBOUND_MODIFY	Le LSP modifie les données sortantes.
LSP_PROXY	Le LSP agit comme un proxy et redirige les paquets.
LSP_REDIRECTOR	Le LSP est un redirecteur réseau.
LSP_SYSTEM	Le LSP est acceptable pour une utilisation dans les services et les processus système.

Un LSP peut appartenir à plusieurs catégories. Par exemple, un pare-feu/LSP de sécurité peut appartenir aux catégories inspecteur (LSP_INSPECTOR) et pare-feu (LSP_FIREWALL).

Si un LSP n’a pas de catégorie définie, il est considéré comme faisant partie de la catégorie Tous les autres. Cette catégorie LSP ne sera pas chargée dans les services ou les processus système (par exemple, lsass, winlogon et de nombreux processus svchost).

La fonction WSCSetApplicationCategory ne peut être appelée que par un utilisateur connecté en tant que membre du groupe Administrateurs. Si WSCSetApplicationCategory est appelé par un utilisateur qui n’est pas membre du groupe Administrateurs, l’appel de fonction échoue et WSANO_RECOVERY est retourné dans le paramètre lpErrno . Cette fonction peut également échouer en raison du contrôle de compte d’utilisateur (UAC). Si une application qui contient cette fonction est exécutée par un utilisateur connecté en tant que membre du groupe Administrateurs autre que l’administrateur intégré, cet appel échoue, sauf si l’application a été marquée dans le fichier manifeste avec un requestedExecutionLevel défini sur requireAdministrator. Si l’application sur Windows Vista ou Windows Server 2008 ne dispose pas de ce fichier manifeste, un utilisateur connecté en tant que membre du groupe Administrateurs autre que l’administrateur intégré doit ensuite exécuter l’application dans un interpréteur de commandes amélioré en tant qu’administrateur intégré (administrateur d’exécution) pour que cette fonction réussisse.

Toute installation de fichier ou configuration spécifique au fournisseur de services doit être effectuée par l’appelant.

Spécifications


Client minimal pris en charge	Windows Vista [applications de bureau uniquement]
Serveur minimal pris en charge	Windows Server 2008 [applications de bureau uniquement]
Plateforme cible	Windows
En-tête	ws2spi.h
Bibliothèque	Ws2_32.lib
DLL	Ws2_32.dll