Voici un problème avec IIS 7.5 et ASP.NET, sur lequel j'ai effectué des recherches et qui ne mène nulle part. Toute aide serait grandement appréciée.
Ma question est la suivante: en utilisant ASP.NET dans IIS 7.5, comment IIS et/ou le système d'exploitation permettent-ils à l'application Web d'écrire dans un dossier tel que C:\dump
lors de l'exécution en pleine confiance? Comment se fait-il que je n'ai pas à ajouter explicitement un accès en écriture à l'utilisateur du pool d'applications (dans ce cas, ApplicationPoolIdentity
)?
C'est ce que je sais:
ApplicationPoolIdentity
.ApplicationPoolIdentity
représente un compte d'utilisateur Windows appelé "IIS APPPOOL\AppPoolName", créé lors de la création du pool d'applications, où AppPoolName est le nom du pool d'applications.IIS_IUSRS
.C:\Users
, C:\Windows
, etc.). Par exemple, votre application aura le droit d'écrire dans certains dossiers, tels que C:\dump
.IIS_IUSRS
ne dispose pas d'un accès en lecture ou en écriture à C:\dump
(du moins pas un accès visible via l'onglet "Sécurité" de l'Explorateur Windows).IIS_IUSRS
, vous obtiendrez une exception SecurityException lorsque vous tenterez d'écrire dans le dossier (comme prévu).Alors, en tenant compte de tout cela, comment l'accès en écriture est-il accordé à l'utilisateur "IIS APPPOOL\AppPoolName"? Le processus w3wp.exe est exécuté sous cet utilisateur. Par conséquent, qu'est-ce qui permet à cet utilisateur d'écrire dans un dossier auquel il ne semble pas avoir d'accès explicite?
Veuillez noter que, si je comprends bien, cela a probablement été fait pour des raisons de commodité, car il serait difficile d’accorder à un utilisateur l’accès à tous les dossiers sur lesquels il doit écrire si vous travaillez sous Full Trust. Si vous souhaitez limiter cet accès, vous pouvez toujours exécuter l'application sous Confiance moyenne. Je souhaite connaître la manière dont le système d'exploitation et/ou IIS autorise ces écritures, même s'il semble n'y avoir aucun accès explicite au système de fichiers.
La ApplicationPoolIdentity
se voit attribuer l'appartenance au groupe Users
ainsi qu'au groupe IIS_IUSRS
. À première vue, cela peut sembler préoccupant, mais le groupe Users
dispose de droits NTFS quelque peu limités.
Par exemple, si vous essayez de créer un dossier dans le dossier C:\Windows
, vous constaterez que ce n'est pas le cas. La ApplicationPoolIdentity
doit toujours pouvoir lire les fichiers des dossiers système Windows (sinon, comment le processus de travail pourrait-il charger dynamiquement les DLL essentielles)?.
En ce qui concerne vos observations sur la possibilité d’écrire dans votre dossier c:\dump
. Si vous examinez les autorisations dans les paramètres de sécurité avancés, vous verrez ce qui suit:
Voir que la permission spéciale est héritée de c:\
:
C'est la raison pour laquelle votre ApplicationPoolIdentity
de votre site peut lire et écrire dans ce dossier. Ce droit est hérité du lecteur c:\
.
Dans un environnement partagé où vous avez plusieurs centaines de sites, chacun avec son propre pool d'applications et son identité de pool d'applications, vous devez stocker les dossiers du site dans un dossier ou un volume pour lequel le groupe Users
a été supprimé et les autorisations définies, par exemple. que seuls les administrateurs et le compte SYSTEM ont un accès (avec héritage).
Vous affecteriez ensuite individuellement les autorisations requises par chaque IIS AppPool\[name]
requis sur son dossier racine de site.
Vous devez également vous assurer que le groupe Users
est supprimé des dossiers que vous créez dans lesquels vous stockez des fichiers ou des données potentiellement sensibles. Vous devez également vous assurer que les applications que vous installez ne stockent pas de données sensibles dans leurs dossiers c:\program files\[app name]
et qu'elles utilisent plutôt les dossiers de profil utilisateur.
Donc, oui, à première vue, il semble que la ApplicationPoolIdentity
dispose de plus de droits qu’elle ne le devrait, mais elle n’a en fait pas plus de droits que ne le dicte l’appartenance à un groupe.
L'appartenance à un groupe de ApplicationPoolIdentity
peut être examinée à l'aide de SysInternals outil Process Explorer . Recherchez le processus de travail en cours d'exécution avec l'identité du pool d'applications qui vous intéresse (vous devrez ajouter la colonne User Name
à la liste des colonnes à afficher:
Par exemple, j'ai ici un pool nommé 900300
qui a une identité de pool d'applications de IIS APPPOOL\900300
. En cliquant avec le bouton droit sur les propriétés du processus et en sélectionnant l'onglet Sécurité, vous voyez:
Comme on peut le voir, IIS APPPOOL\900300
est un membre du groupe Users
.
Faites un clic droit sur le dossier.
Cliquez sur Propriétés
Cliquez sur l'onglet Sécurité. Vous verrez quelque chose comme ça:
Cochez/décochez tout accès que vous devez accorder au compte
Cliquez sur le bouton Appliquer, puis sur OK.
Chaque pool d'applications dans IIs crée son propre dossier utilisateur sécurisé avec une autorisation PLEIN lecture/écriture par défaut sous c:\users. Ouvrez votre dossier Utilisateurs et voyez quels sont les dossiers du pool d'applications, cliquez avec le bouton droit de la souris et vérifiez leurs droits pour le compte virtuel du pool d'applications attribué. Votre compte de pool d'applications devrait déjà être ajouté avec un accès en lecture/écriture attribué à sa racine et à ses sous-dossiers.
Ainsi, ce type d'accès au stockage de fichiers est automatiquement effectué et vous devriez pouvoir écrire ce que vous voulez dans les dossiers du compte d'utilisateur du pool d'applications sans rien changer. C'est pourquoi les comptes d'utilisateurs virtuels pour chaque pool d'applications ont été créés.