Hej,

Jag får ett SecirityException som jag inte riktigt vet hur jag skall få bukt med. Den inträffar när jag skall öppna en OleDbConnection och dess meddelande är "Request failed". Genom att titta på anropsstacken kan jag se att anropet går via en av våra "generella" klassbibliotet. Detta klassbibliotek använder sig av en rad attribut på assembly-nivå för Code Access Secirity (CAS):

[assembly: SecurityPermission(SecurityAction.RequestOptional, UnmanagedCode=true)]
[assembly: ReflectionPermission(SecurityAction.RequestOptional, MemberAccess=true, TypeInformation=true)]
[assembly: FileIOPermission(SecurityAction.RequestOptional, Unrestricted=true)]
[assembly: System.Web.AspNetHostingPermission(SecurityAction.RequestOptional, Unrestricted=true)]
[assembly: System.Data.OleDb.OleDbPermission(SecurityAction.RequestOptional, Unrestricted=true)]

Jag är verkligen inte hemma på CAS, men jag misstänker att det är något som saknas i denna lista. Denna misstanke blir inte mindre av att jag kan utföra samma sak utan problem om jag bara undviker att gå via klassbiblioteket. Några förslag på vad det kan vara?

Det deklarativa som står är Unrestricted=true, vilket inte borde ge dig fel. Men det kan även finnas imperlativa regler längre ner i koden som kan ställa till det. Du kanske måste ta en titt där. Det kan till och med vara så att du inte har rättigheter i databasen. Det beror helt på hur systemet är designat och väldigt svårt att utifrån detta säga vad som inte uppfyller kraven.

Fråga er designer, denne är nog den som bäst kan svara på detta.

Hej Pelle,

Jag har skapat ett litet testprogram bestående enbart av följande kod:

using System;
using System.Data.OleDb;
using System.Security.Permissions;

[assembly: FileIOPermission(SecurityAction.RequestOptional, Unrestricted=true)]

namespace ConsoleApplication1
{
    class Class1
    {
        [STAThread]
        static void Main(string[] args)
        {
            OleDbConnection conn = new OleDbConnection(@"file name=C:\database.udl");
            conn.Open();
        }
    }
}

Denna kod kommer att ge samma security exception (Request failed) som i den "riktiga" applikationen. Tar jag bort assembly-attributet går allt bra. Byter jag ut det mot ett annat säkerhets-attribut får jag samma exception. Om jag specar ett säkerhetsattribut (på assembly-nivå) måste jag tydligen även speca ett som tillåter mig att öppna min connection. Frågan är vilket.

Jag har prövat med

[assembly: OleDb.OleDbPermission(SecurityAction.RequestOptional, Unrestricted=true)]

och även (som attribut på Main-funktionen)

[OleDbPermission(SecurityAction.Demand, ConnectionString=@"file name=C:\database.udl")]

men utan framgång. Vad är det för magi som måste till för att få detta att fungera???

Kolla i (caspol.exe) och se vilka beroenden som finns och krävs. Det är också så att det konto som kör programmet måste vara tilldelad de grupper som krävs i applikationen och dess tillhörande assemblys.

Huga! Det där caspol.exe var ju inte att leka med. Jag tror jag behöver gå någon kurs eller nått för att få kläm på det här med CAS. Vi har dock löst det "akuta" problemet genom att ändra så att anrop för att öppna connection inte längre går via klassen i det generella biblioteket.

Men, det verkar som om vi skulle ha kunnat ändrat från:

[assembly: FileIOPermission(SecurityAction.RequestOptional, Unrestricted=true)]

till:

[assembly: FileIOPermission(SecurityAction.RequestMinimum, Unrestricted=true)]

Detta gjorde iallafall susen i min lilla konsolapplikation. Jag gissar att Connection.Open inte fick läsa UDL-filen annars, men hur man skall veta sådant fattar jag inte.

Finns det verkligen inte något sätt att se vilket permission som saknas när man får ett SecirityException? Detta är ju inte helt lätt att gissa sig till, även givet informationen från caspol.exe. Att gå den vägen känns "bakvänt" tycker jag.

Håller med. Håller just på att plugga inför den och det är minst sagt mycket att hålla reda på.
Skönt det löste sig i alla fall..