[C#] System.Security.PermissionSet Exception

[Verwijderd]

Hallo,

Ik heb een kleine applicatie geschreven voor onze automatiseringsafdeling, niets bijzonders, slechts een formuliertje wat uit een XML bestand dynamisch enkele knoppen laat en vervolgens de applicatie die geassocieerd is met de knop uitvoeren dmv.

C#:

private void RunExternalProcess(string location)
        {
            Process File = new Process();
            File.EnableRaisingEvents = false;
            File.StartInfo.UseShellExecute = true;
            File.StartInfo.FileName = location;
            File.Start();
            File.Dispose();
        }

Lokaal werkt dit prima, maar zodra ik de applicatie op een netwerkschijf plaats, zodat deze toegankelijk is vanaf meerdere werkstations loop ik tegen een SecurityException aan.
Deze wordt, waarschijnlijk, veroorzaakt door ontbrekende rechten voor het uitvoeren voor het uitvoeren van dergelijke code.
Nu wil ik dit natuurlijk omzeilen danwel oplossen, maar het ontbreekt mij aan gerichte kennis om dit aan te pakken en zomaar lukraak op de server 'klooien' zie ik, zoals jullie zullen begrijpen, niet echt zitten.
Mijn vraag is dus of jullie misschien tegen dergelijke constraints zijn aangelopen en hoe jullie dit opgelost hebben.

Wat meer info:

code:

The action that failed was:
LinkDemand
The type of the first permission that failed was:
System.Security.PermissionSet
The zone of the assembly that failed was:
Intranet

[whoami]

Gisteren is er hier een gelijkaardig topic over geweest:
Het is zo dat, als je een .NET applicatie vanaf een netwerk-share uitvoert, die applicatie onder de permission-set van de 'Local Intranet zone' draait. Die specifieert dat je dus niet zomaar file I/O kunt doen.
Je kan dit oplossen door op iedere pc waar die applicatie draait, de rechten van de local intranet-security zone te verhogen, maar da's omslachtig.
Je kan echter er ook voor kiezen om je applicatie via ClickOnce te deployen (als je gebruik maakt van .NET 2.0).
Wat je ook kan doen -maar die manier zou ik eerst eens even moeten testen- is, dat je de nodige permissies 'Assert' wanneer je ze nodig hebt (en dan opnieuw Revert eens je de operatie gedaan hebt).
Bv:
_{pseudo-code; te lui om de juiste classes / methods op te zoeken}

code:

FileIOPermission p = new FileIOPermission ( ... );
try
{
    p.Assert();
    // doe hier file IO.
}
finally
{
   p.Revert();
}

Echter, ik heb geen idee of dit gaat werken, maar ik denk van wel.

[ Voor 31% gewijzigd door whoami op 07-06-2007 17:31 ]

[Verwijderd]

Niet gehinderd door enige kennis vraag ik me dan toch of je het probleem niet verschuifd, maar dan naar je asserts, het security niveau blijft toch gewoon gehandhaafd en zal dan nog steeds een SecurityException oproepen, of vergis ik me?

[whoami]

Assert is a method that can be called on code access permission classes and on the PermissionSet class. You can use Assert to enable your code (and downstream callers) to perform actions that your code has permission to do, but its callers might not have permission to do. A security assertion changes the normal process that the runtime performs during a security check. When you assert a permission, it tells the security system not to check the callers of your code for the asserted permission.

CAUTION Use assertions carefully because they can open security holes and undermine the runtime's mechanism for enforcing security restrictions.
Assertions are useful in situations in which a library calls into unmanaged code or makes a call that requires a permission that is not obviously related to the library's intended use. For example, all managed code that calls into unmanaged code must have SecurityPermission with the UnmanagedCode flag specified. Code that does not originate from the local computer, such as code that is downloaded from the local intranet, will not be granted this permission by default. Therefore, in order for code that is downloaded from the local internet to be able to call a library that uses unmanaged code, it must have the permission asserted by the library. Additionally, some libraries might make calls that are unseen to callers and require special permissions.

Het proberen waard zou ik zeggen.

[Verwijderd]

Ga ik me zeker eens in verdiepen, ben er nog niet bekend mee, maar bedankt tot dusver

[Verwijderd]

Voor .NET 1.1 zou je ook het volgende kunnen doen op de client:

Control Panel -> Administrative Tools -> Microsoft .NET Framework Wizards -> Trust an Assembly

Je moet dit voor die Assembly doen die de fout veroorzaakt. Op deze manier kan je het trust level voor een bepaalde assembly verhogen.
Je assembly moet dan wel een strong name hebben.

[Verwijderd]

Ik gebruik zelf .NET 2.0, maar op de server is de configuratie tool voor .NET 2 niet beschikbaar, want de SDK is er niet op geinstalleerd.
Probeer het van de week wel even met de asserts, nu nog geen tijd voor gehad ivm. schoolwerk

[Verwijderd]

Het duurde even voor ik de kans had weer even naar dit dingetje te kijken ,maar ik kom er niet echt uit.

Ik probeer een stuk code te asserten:

C#:

private void RunExternalProcess(string location)
        {
            FileIOPermission fio = new FileIOPermission(PermissionState.Unrestricted);
            try
            {
                fio.Assert();
                
                Process File = new Process();
                File.EnableRaisingEvents = false;
                File.StartInfo.UseShellExecute = true;
                File.StartInfo.FileName = location;
                File.Start();
                File.Dispose();

            }
            finally
            {
                fio.Deny();
            }
        }

De solution wordt vanaf een netwerk schijf geladen in VS2005.
Het compileert wel en is ook uitvoerbaar en het stelt me in staat bestanden uit te voeren, maar zodra ik het compile naar een release gaat het geheel over zijn nek.

Help

[whoami]

#define: over z'n nek gaan.

Kan je trouwens niet met clickonce werken ipv uit te voeren vanaf een share ?

[Verwijderd]

Dezelfde error; een failing permissionset.

Ook met clickonce ben ik nog niet bekend, maar het liefst zou ik het op deze wijze op lossen als ik eerlijk ben, simpelweg een executable runnen lijkt me toch het meest eenvoudig (maar ik kan me natuurlijk vergissen).

[whoami]

ClickOnce is ook simpelweg een exectutable runnen.
Enige verschil is dat je eerst op een linkje moet klikken, kan je die executable installeren. Iedere keer je het programmatje opstart, wordt er gechecked of er een nieuwe versie beschikbaar is, en dan kan die ook gedownloaded worden. Simpel.

[Verwijderd]

Niet eens een linkje; het openen van de juiste .application file is al voldoende bij ClickOnce (daar verwijst dat linkje ook naar ). Komt uiteindelijk op hetzelfde neer als gewoon een .exe openen.

Zie MSDN voor meer informatie over ClickOnce. Direct zelf klooien kan ook: zie tabblad Publish in je project properties. Kan overigens zijn dat je een code signing certificaat nodig hebt die gesigneerd is door een vertrouwde instantie (kost je een paar honderd bucks). Anders zelf zo'n ding laten signen door de CA op de domeinserver ofzo.

[ Voor 3% gewijzigd door Verwijderd op 05-07-2007 01:50 ]

[Verwijderd]

Inmiddels weer een weekje verder en weer achter het bureau aanbeland, heb even gestoeid met de publish optie in Visual Studio.

En het werkt prima, bedankt voor de tip whoami & negerzoen