New problem with 7.2.77 that did not exist in prior versions

[guilford]

I just upgraded from 7.1.58 to 7.2.77 and have used many, many prior versions of DevArt. We are seeing a new problem with 7.2.77 that we've never seen before. When we try to connect to the database from a windows service running under the local NetworkService account with this connection string:

"User Id=lookup_data_service;Password=dontyouwish;Server=DATABET2;Pooling=False;"

the service fails on startup with this message in the EventLog:

"Service cannot be started. System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: An error occurred while executing the command definition. See the inner exception for details. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.Data.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details. ----> System.ComponentModel.Win32Exception: Access is denied
at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)
at System.Diagnostics.NtProcessManager.GetModuleInfos(Int32 processId, Boolean firstModuleOnly)
at System.Diagnostics.NtProcessManager.GetFirstModuleInfo(Int32 processId)
at System.Diagnostics.Process.get_MainModule()
at Devart.Common.Entity.bx.a()
at Devart.Common.Entity.bx.b()
at Devart.Data.Oracle.Entity.an.o()
at Devart.Data.Oracle.Entity.w.a(CommandBehavior A_0)
at Devart.Data.Oracle.Ent...
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp."

I can solve the problem by running any prior version of DevArt (7.1.58, or several of the 6.* releases), but it fails consistently with 7.2.77 when the ONLY change we are making to the service is which version of DevArt we are referencing. I can also solve the problem by changing the windows service to run under a domain account that has a corresponding account mapped in the Oracle database. However, with the connection string specified as above, I shouldn't have to use any specific account at all since the username and password are supplied in the connection string. After successfully connecting when the service is running under a domain account that maps to the Oracle database, if I change it back to run under the NetworkService account it fails again.

We have a couple of other Windows services connecting to this same database using connection strings like this:

"User Id=;Password=;Server=CAMSBET2;Pooling=False;"

Those services that pass along the authenticated user credentials (instead of an explicit username and password) still work correctly, just like they always have. It seems to only be a problem with the connection string that specifies the username and password running under an local account that doesn't map to an account in the Oracle database, even though we have been using this exact configuration for several users with many prior versions of DevArt.

This is impacting our production environment and is causing a great deal of trouble for us.

[guilford]

In the EventLog information I included in my initial post the stack trace data was cut off because of the field size limitations of the EventLog service. However, I have now captured the entire call stack so that you can see the full trace of the "access is denied" problem we are seeing:

Service Model Detail Inner Exception Message: Access is denied
Service Model Detail Inner Exception Type: System.ComponentModel.Win32Exception
Service Model Detail Inner Exception Stack Trace: at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)
at System.Diagnostics.NtProcessManager.GetModuleInfos(Int32 processId, Boolean firstModuleOnly)
at System.Diagnostics.NtProcessManager.GetFirstModuleInfo(Int32 processId)
at System.Diagnostics.Process.get_MainModule()
at Devart.Common.Entity.bx.a()
at Devart.Common.Entity.bx.b()
at Devart.Data.Oracle.Entity.an.o()
at Devart.Data.Oracle.Entity.w.a(CommandBehavior A_0)
at Devart.Data.Oracle.Entity.w.b(CommandBehavior A_0)
at System.Data.Common.DbCommand.ExecuteReader(CommandBehavior behavior)
at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)

[guilford]

After further investigation, I believe the actual problem is that things are working correctly if the first entity framework query executes under the context of an adminstrator on the local machine and fails if it is run under the context of someone who does not have local admin privileges on the box. We have not seen this in prior versions of DevArt. From the error log I included above:

Service Model Detail Inner Exception Message: Access is denied
Service Model Detail Inner Exception Type: System.ComponentModel.Win32Exception
Service Model Detail Inner Exception Stack Trace: at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)
at System.Diagnostics.NtProcessManager.GetModuleInfos(Int32 processId, Boolean firstModuleOnly)
at System.Diagnostics.NtProcessManager.GetFirstModuleInfo(Int32 processId)
at System.Diagnostics.Process.get_MainModule()
at Devart.Common.Entity.bx.a()
at Devart.Common.Entity.bx.b()
at Devart.Data.Oracle.Entity.an.o()
at Devart.Data.Oracle.Entity.w.a(CommandBehavior A_0)
at Devart.Data.Oracle.Entity.w.b(CommandBehavior A_0)
at System.Data.Common.DbCommand.ExecuteReader(CommandBehavior behavior)
at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)

I think the problem is where DevArt.Common.Entity.bx.a() calls into System.Diagnostics.Process, which eventually calls into System.Diagnostics.ProcessManager.OpenProcess. The OpenProcess calls succeeds if the run context is a local administrator on the box and fails if the run context is not a local administrator on the box. Can you please tell me what is happening in DevArt.Common.Entity.bx.a() and what elevated permission we need to grant in order to get this to work like it has in every previous version we have used.

[guilford]

Can anyone from DevArt please provide some help with this issue? To recap in the simplest possible terms, I am using dotConnect for Oracle and I have a windows service that makes EF calls via DevArt. With 7.1.58 and any prior version the windows service will run just fine under the built in NetworkService account permissions. If I upgrade to 7.2.77 (and that is the ONLY change I make), the windows service will no longer run under the NetworkService account, throwing the errors shown above. It does run correctly if I run the windows service under a domain account that is an admin on the server box instead of the NetworkService account we have been using in the past, so this seems to be a permission issue. Can you please provide some information regarding what change you made with 7.2.77 that requires higher permissions than previous versions?

[Shalex]

We have tried to retrieve data via Entity Framework using dotConnect for Oracle v 7.2.77 on Windows 2003 with default settings (application: Windows Service; account: built in NetworkService). It works in our environment. Our investigation is in progress but we appreciate any additional information about your environment/project which can help us to reproduce the problem.

[Shalex]

The bug with demanding extra permissions when running under restricted user account is fixed. We will post here when the corresponding build of dotConnect for Oracle is available for download.

[Shalex]

New build of dotConnect for Oracle 7.2.96 is available for download!
It can be downloaded from http://www.devart.com/dotconnect/oracle/download.html (trial version) or from Registered Users' Area (for users with active subscription only).
For more information, please refer to http://forums.devart.com/viewtopic.php?f=1&t=25020.