Then, using caspol, I create a permissionset that states that the members of the permissionset cannot write to the c:\file.txt file, and apply it to a code group. This codegroup is then applied to the console application I just created.
If I run this in Win7, with UAC at default - the app crashes, stating that the app didn't have the security permission to write to the file.
However, if I run the app with UAC turned off - the app writes perfectly to the file. No crash, no warning, no nothing.
It's as if turning UAC off completes disables CAS. That can't possibly be right in any way, shape or form.
Kan det her virkeligt være rigtigt? Hvis det er, så betyder det jo at man kan override CAS TOTALT bare ved at slå UAC fra.
Ja, men hvorfor bliver CAS disabled bare fordi man ikke vil se UAC beskeder om at "er du sikker på at du vil trykke ok?".
De to ting burde da ikke hænge sammen. Jeg har jo netop været inde og frivilligt sige, at min app.exe fil ikke skal have lov til at skrive til c:\, men den gør det alligevel.
Man kunne jo forestille sig et third party assembly, som man ville være sikker på ikke skrev ned i ens c:\windows directory, men fordi UAC er slået fra, har fuldt ud lov til at gøre det alligevel.
Det jeg mener er, at inde i mscorcfg.msc, så sætter jeg membership til at være URL og så peger jeg på c:\app.exe som er min application. Så rammer den kun det ene assembly.
Og igen, problemet er, at hvis man disabler UAC på en win7, så disabler du samtidigt CAS policies der er sat inde i mscorcfg.msc via codegroups og permissionsets.
Problemet er der ikke i WinXP fordi der findes UAC ikke.
Desværre ikke. Det handler om hvordan man får en application til at køre med elevated priviledges. Det ændrer ikke på, at hvis man slår UAC fra på en maskine, så virker CAS heller ikke i de assemblies man afvikler.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
