When creating a SQL Server CLR stored procedure, I noticed that I couldn't reference anything in the .net framework as I would normally. After some reading around, I realised that assemblies needed to be loaded into the database first.
Therefore, I loaded in the ones I need but due to P/Invoke had to use the UNSAFE permission set. I can now reference them in my stored procedure code and everything works fine.
However, I'm a little concerned about having to set them to UNSAFE when I don't really know what they are doing. So my question is this:
Is it ok to load the .net framework in as UNSAFE without exactly what it's doing?
And how would doing so compromise security/robustness/scalability of sql server (as microsoft warn it could)?
Many thanks.
It could change the registry, restart services, reboot the server etc. Nothing too important ;-) A simple chart with the differences
See this question too (no answers though) SQL Server 2008: How crash-safe is a CLR Stored Procedure that loads unmanaged libraries
Of course, what are you doing that requires UNSAFE access?
When you use the SQL database engine on a server which is hosting many many public websites you don't know anything about as a server administrator (or DBA or whoever responsible), you should restrict their access and damn it's important! Also if you have a DBA in a restricted area, where data matters the most in some big companies, again it's the most important thing.
In my point of view, you should give your application as it needs to see, nothing more. If you don't need to see the registry for example, why you wanna give unrestricted access to the assembly? You have no idea how dangerous it could be if somebody injects the code of your application and hijack into the database (also with an unrestricted access!).
Hope it helps
This question is specific to loading .Net Framework assemblies that are not in the set of Supported .NET Framework Libraries, so I will focus on the context being Microsoft supplied DLLs rather than any random DLL.
The difference between the assemblies in the "Supported" list and those not in the list comes down to the fact that the supported ones "have been tested to ensure that they meet reliability and security standards for interaction with SQL Server" (as noted in the "Supported Libraries" page linked above). The main issue is more so the "reliability" than the "security". The assemblies in the supported list have been verified to behave consistently as expected and without any bugs or odd side-effects. The functionality has been tested to work with various languages and collations, etc.
Some .Net Framework assemblies that are not in the supported list can be loaded with a PERMISSION_SET set to SAFE. This, however, does not guarantee desired behavior. And some can be loaded as UNSAFE without necessarily indicating that there will be a problem.
As an example of not guaranteeing behavior: I have loaded System.Drawing in order to do some simple image manipulation. I tested manipulations when the image was supplied directly via byte[] / VARBINARY(MAX) as well as when it was supplied by a filepath and read from disk. Everything worked as expected. I sent that to someone in Germany whose Windows and SQL Server were both set to "German" as the language. He was able to get the expected results when supplying the image directly. But when he supplied a filepath it didn't work.
And regarding undesired behavior, SQL Server will display the reasons why the assembly can't load as either SAFE or EXTERNAL_ACCESS when you try to do it. For example:
CREATE ASSEMBLY [System.Drawing]
AUTHORIZATION [dbo]
FROM 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Drawing.dll'
WITH PERMISSION_SET = SAFE;
Results in:
Warning: The Microsoft .NET Framework assembly 'system.drawing, version=4.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a, processorarchitecture=msil.' you are registering is not fully tested in the SQL Server hosted environment and is not supported. In the future, if you upgrade or service this assembly or the .NET Framework, your CLR integration routine may stop working. Please refer SQL Server Books Online for more details.
Msg 6218, Level 16, State 2, Line 1
CREATE ASSEMBLY for assembly 'System.Drawing' failed because assembly 'System.Drawing' failed verification. Check if the referenced assemblies are up-to-date and trusted (for external_access or unsafe) to execute in the database. CLR Verifier error messages if any will follow this message
[ : System.Drawing.BufferedGraphicsContext::bFillColorTable][mdToken=0x600013c][offset 0x00000053][found address of Byte] Expected numeric type on the stack.
[ : System.Drawing.BufferedGraphicsContext::bFillColorTable][mdToken=0x600013c][offset 0x00000043][found Native Int][expected address of Byte] Unexpected type on the stack.
[ : System.Drawing.BufferedGraphicsContext::bFillColorTable][mdToken=0x600013c][offset 0x00000027][found Native Int][expected address of Byte] Unexpected type on the stack.
[ : System.Drawing.Icon::ToBitmap][mdToken=0x6000349][offset 0x00000084][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : System.Drawing.Icon::ToBitmap][mdToken=0x6000349][offset 0x000000E4] Unmanaged pointers are not a verifiable type.
[ : System.Drawing.Icon::GetShort][mdToken=0x6000356][offset 0x00000002] Unmanaged pointers are not a verifiable type.
...
If you are not going to use any of those methods or types, then you likely will not have any issues. There is just no way to separate out the "safe" stuff from the "unsafe" items.
Another example of guilt-by-association, but even farther removed, is:
CREATE ASSEMBLY [System.Web]
AUTHORIZATION [dbo]
FROM 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Web.dll'
WITH PERMISSION_SET = SAFE;
Results in:
Warning: The Microsoft .NET Framework assembly 'system.web, version=4.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a, processorarchitecture=x86.' you are registering is not fully tested in the SQL Server hosted environment and is not supported. In the future, if you upgrade or service this assembly or the .NET Framework, your CLR integration routine may stop working. Please refer SQL Server Books Online for more details.
Warning: The Microsoft .NET Framework assembly 'microsoft.build.framework, version=4.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a, processorarchitecture=msil.' you are registering is not fully tested in the SQL Server hosted environment and is not supported. In the future, if you upgrade or service this assembly or the .NET Framework, your CLR integration routine may stop working. Please refer SQL Server Books Online for more details.
Warning: The Microsoft .NET Framework assembly 'system.xaml, version=4.0.0.0, culture=neutral, publickeytoken=b77a5c561934e089, processorarchitecture=msil.' you are registering is not fully tested in the SQL Server hosted environment and is not supported. In the future, if you upgrade or service this assembly or the .NET Framework, your CLR integration routine may stop working. Please refer SQL Server Books Online for more details.
Msg 6212, Level 16, State 1, Line 1
CREATE ASSEMBLY failed because method 'TypeDescriptorRefreshed' on type 'System.Windows.Markup.ValueSerializer' in safe assembly 'System.Xaml' is storing to a static field. Storing to a static field is not allowed in safe assemblies.
As you can see, System.Web is actually, by itself, fine for SAFE, but it has dependent assemblies and those are being auto-loaded. The first dependent assembly, microsoft.build.framework also has no issues (at least not that can be verified, though it is possible that something that is disallowed in SAFE is there but can only be caught at run-time). But the second dependent assembly does have an issue that can be verified upon loading the assembly: it is "storing to a static field". This is a problem for reliability more than security because classes are instantiated one time (well, per App Domain, meaning: per-database, per owner) and shared across the SPIDs to use (which is why only static methods are accessible in SQLCLR). Hence, static class-level variables are technically sharing information between sessions (i.e. SPIDs) and that can very easily cause unexpected behavior. But at the same time, if you only want to use HtmlString.ToHtmlString(), then you probably aren't making use of System.Xaml. So why doesn't it just load System.Web as SAFE and System.Xaml as UNSAFE? Probably because code in SAFE assemblies is not allowed to call code in UNSAFE assemblies (at least not in SQLCLR).
CONLUSION
So is it OK to load UNSAFE .Net Framework assemblies? That really should come down to testing. Lots of testing (and not just a single thread on your dev box, but real testing). If everything behaves as expected then you should be fine. But, if something does not behave as expected, then it is not a bug that can be reported to Microsoft because it has already been declared as unsupported.
EDIT:
And here is a more official answer to this question, which lists a few situations where problems could occurr: Support policy for untested .NET Framework assemblies in the SQL Server CLR-hosted environment
Related
I have a Classic ASP website that uses a DLL to create a Msxml2.DOMDocument object and returns that to the browser (called from an jQuery ajax call). I run the website on two computers. Both have the same classic ASP, and both have the same version of the DLL file registered.
Under one environment the returned XML object has a "parseError" property, and has an "xml" property that contains a string representation of the XMl in the object. The object type of the XML returned by the server is IXMLDOMDocument2 (as viewed in the browser's debugging tools).
But in my second environment the returned object seems to be of type "XMLDocument", and it doesn't have the "parseError" or "xml" properties.
In both environments, Windows shows that MSXML4 SP2 is installed in "Programs and Features", but only versions 3.0 and 6.0 are listed in this registry key:
HKEY_CLASSES_ROOT\CLSID{2933BF90-7B36-11D2-B20E-00C04F983E60}\VersionList
Both environments have identical ASP code, and I've registered the same DLL file, which generates the XML to return, in both environments.
What might cause one environment to return a different XML object under the same conditions?
I'm not sure where to begin to solve this.
I figured out the issue, it was silly. The website in question is very old, and most of the pages don't work unless you have IE's Compatibility Mode enabled. Compatibility Mode was enabled in IE for the environment which worked as I expected (it returns an IXMLDOMDocument2 object), but it was not enabled in the other environment.
Shortly I ve Windows Server 2012 R2, AEM Forms(6.2), SQLServer(2014) and Workbench(6.2) in same server. At first when i install and configure all of them, i can check out or in my applications from Workbench succesfully. However After my software team executes some scripts at Database, we can not check in/out from workbench. The worst thing when i click check out, workbench gives any error. any log. on event log or server application. It gives nothing and don't do my transaction. I saw at forums some people have same issue but nobody writes solution.
Please if any one knows the solution, share with us. What's wrong with my workbench? what to do fix this issue?
The query that your software team ran turns off security on every single LiveCycle service and makes them run as the system user. This includes the services used by Workbench and is very bad. Some of the services rely on knowing who is logged in to operate correctly. In particular, how can LiveCycle know who has checked in/out a resource if the service always runs as system?
Your best bet is to restore the LiveCycle database - or at least the tb_sc_service_configuration table to be where it was before you ran the script.
If you need to remove security on individual services, you should do it through the admin console, but only do it for your processes. Never do it for systems services unless the Adobe documentation says it is OK.
As JeremyP pointed out, modifying the Adobe database directly is a bad idea. The database should be treated as a black box that is only manipulated by Adobe code (either by doing things in the Adobe tools or making calls to Adobe APIs).
You can either make security changes manually through the adminui (as he indicates, which is the most common way of doing it) or programatically using the Adobe client APIs. See the following links for sample code that uses the APIs:
Removing Security - http://help.adobe.com/en_US/livecycle/10.0/ProgramLC/WS624e3cba99b79e12e69a9941333732bac8-7f35.html
Setting the runAs user - http://help.adobe.com/en_US/livecycle/10.0/ProgramLC/WS624e3cba99b79e12e69a9941333732bac8-7f38.html
My company, 4Point, offers AEM Forms consulting services. We have an in-house Apache Ant library that wraps the code above to automate this (and other) common tasks that are typically required when deploying (and redeploying) AEM Forms solutions. It can be included as part of a consulting engagement.
I'm in the process of upgrading an existing application to .NET Core (DNX SDK 1.0.0-rc1-update2) that uses SQL Servers FILESTREAM feature for reading/writing large BLOBs to the database. It uses the SqlFileStream class to achieve this however it doesn't appear to be available in .NET Core. Here are my references in project.json:
"frameworks": {
"net451": {
"frameworkAssemblies": {
"System.Runtime": "4.0.10.0",
"System.Collections": "4.0.0.0"
}
},
"dotnet5.4": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-23516",
"System.Data.Common": "4.0.1-beta-23516",
"System.Data.SqlClient": "4.0.0-rc2-23623",
"System.Collections": "4.0.11-beta-23516",
"System.IO.FileSystem": "4.0.1-beta-23516",
"System.Linq": "4.0.1-beta-23516",
"System.Runtime": "4.0.21-beta-23516",
"System.Threading": "4.0.11-beta-23516"
}
}
}
I've tried searching SO and Google, both of which have absolutely nothing on the subject.
Can someone please confirm if its actually unavailable or if its in another package I'm unaware of?
I realize the question is old, but I just came across the issue - implementing SqlFileStream - listed on the github repo for CoreFX (.NET Core foundational libraries) and thought I'd mention it here. Here's a link to the issue, for reference: https://github.com/dotnet/corefx/issues/15652
To recap: The issue is implementing SqlFileStream. It's currently an open issue, but not on the horizon anytime soon. One of the contributors states "if there are any Windows specific dependencies, we may not bring it in Core."
I've actually been interested in this for a while and have taken some time over the last few days.
Unfortunately, FILESTREAM uses several NTFS and NT specific system calls (NtCreateFile, DeviceIoControl in particular, but a few others to support those as well) to manage access to the file. Also, unfortunately, as of this writing the latest MSSQL CTPs for Linux don't support FILESTREAM, and there's little clarity as to whether that's on the roadmap or where it might be (strangely, you can restore a database that supports FILESTREAM but FileTable doesn't seem to be supported).
There are two problems here: it's not clear that replacing the NT specific APIs would respect transactional integrity (or even work at all), and it's not clear that they could ever work from a non-Windows environment anyway. Because of these facts, I don't see SqlFileStream being supported any time in the near future for core.
There is some precedent for Windows Only type of low level, for example in System.Net.Socket.IOControl. SqlFileStream could perhaps take a similar path. Alternatively, it might be possible to build a specific SqlFileStream NuGet package, but have it only be supported/runnable on Windows. I'm not sure how valuable this would be though - if you're going to P/Invoke in a Windows only way to begin with, why not just P/Invoke to a .NET 4.6.x dll?
Cross posting this to the github issue: https://github.com/dotnet/corefx/issues/15652
Edit: As an alternative to P/Invoke, you could certainly create some other kind of service (RESTful, WCF, some other pipe or TCP or even memory mapped file) in .NET 4.x for a .NET Core library or application to access.
I have two client-side RIA services projects, each mapped to server-side RIA assembly for code-gen etc.. Let's call them domains A and B.
To make matters slightly more complicated, on the server side, domain project B references domain project A.
In project A on the server side, I create an Enum, and call the file MyEnum.shared.cs. I build it, and then build the client side (Silverlight) proxy projects. I then get a compile error: -
"The type MyEnum exists in both DomainProjectA.dll and DomainProjectB.dll."
The problem is that both my client-side proxy projects have copied this Enum file across, so the solution fails as its generated twice. I have proved this by looking at the hidden files in both proxy projects.
Why is this happening? How can I stop it from happening :)
Cheers
Isaac
I'm now fairly sure that this problem is caused because the type generation on the client-side proxy projects is sourced from all types exposed on the server assembly or any referenced assemblies; this also applies to .shared files.
I cannot access ANY database by ANY means from within Delphi XE Professional. What I mean by accessing the data base is:
having the live database appear via
components in the Object Inspector,
when the connected property is set
to true
using the Data Explorer to create
and explore database connections
EDIT:
SORTED !!
The core problem is that communication into the database, including specifically the communication generated by the IDE and any code built using the drivers was problematic.
Confounding and masking sub-issues were:
Missing or misplaced DLLs.
The Data Explorer does not fully support dbExpress drivers.
There is a bug within the 2009 IDE code, found by Chee-Yang Chau when writing the dbxFirebird driver, which limits static linking of drivers into Delphi. It is not known if this bug extends to 2010 or XE.
When using the Object Inspector, it is easy to cause the IDE to revert changed connection parameters to their default values.
Some drivers had incorrect default values (eg assuming the client dll was always gdb32.dll irrespective of whether the database was Interbase or Firebird).
Installation of two versions of Interbase led to some clashes in database communication - server names generated by the tools were odd; and the view of the databases depended on which installation of the Interbase tools were used.
The documentation available is of varying dates; refers to different versions; and as a result often appears contradictory.
END EDIT:
Approaches tried:
Multiple databases
Multiple different drivers/components
Accessing the database through other external tools, such as IBSQL and Flame Robin.
Raising questions (here and here) on SO.
Raising questions on the support forums for Firebird, Embarcardo, and Flame Robin.
Environment:
OS: Windows 7 Ultimate 64bit:
Delphi Embarcadero® RAD Studio XE Professional Version 15.0.3953.35171
Database: W1-V2.5.0.26074 Firebird 2.5 (64 bit)
Connection technology: dbExpress
Delphi Professional does not support Firebird with the native dbExpress drivers that come with Delphi. You need the Enterprise or Architect version of Delphi in order for the native firebird dbExpress driver to work.
I have Delphi 2010 Professional. I didn't want to spend the extra money on the E or A version and I failed to read the feature matrix to see that the Firebird dbExpress driver is not available with the Pro version.
I have found a few really nice videos that show how to connect to Firebird using Delphi. However, when I tried to follow along with my Professonal version nothing worked.
Shame on me and more shame on Embarcadero for touting that Delphi supports Firebird in big bold print but not mentioning that you need the Enterprise or Architect version except in the tiny fine print.
I can now write code to access Firebird within the IDE. I have (limited, but sufficient) access to the drivers within the IDE. Specifically, the drivers appear in the Data Explorer, which can be used to generate default values for the SQLConnection (dbExpress component). These can be accessed and used within the Object Inspector. The workaround to the IDE bug quoted below is necessary to ensure the communication parameters are correct. When writing database code, it is necessary to compile in the source for the dbExpress driver.
The following code is the minimum, with minimum parameter set, necessary to establish and test a database connection:
unit Unit2;
interface
uses Classes, SqlExpr, Dialogs, dbxDevartInterbase;
var SQLConnection1 : TSQLConnection;
implementation
{$R *.dfm}
begin
SQLConnection1 := TSQLConnection.Create(nil);
with SQLConnection1 do
begin
ConnectionName := 'TestConnection';
DriverName := 'DevartInterBase';
LibraryName := 'dbexpida40.dll';
VendorLib := 'fbclient.dll';
GetDriverFunc := 'getSQLDriverInterBase';
Params.Clear;
Params.Add('User_Name=SYSDBA');
Params.Add('Password=masterkey');
Params.Add('Database=localhost:C:\Program Files\Firebird\Firebird_2_5\examples\empbuild\employee.fdb');
Open;
If Connected then ShowMessage('Connection is active');
Free;
end;
end.
The workaround, courtesy of Bob Swart on one of the Codegear forums is:
The trick is to select a
ConnectionName value, which will then
assign a value to the Driver property
and all other properties like
LibraryName, VendorLib and
GetDriverFunc.
Then, make changes - if needed - to
the subproperties of the Driver
property, and finally clear the name
of the Driver property.
This will leave all your changes in
the Params list (which you can also
manually edit if you wish).
Note: leave the ConnectionName set -
if you clear that one, the parameters
will be cleared again.
Now you can compile your application
and deploy it without the need for
dbxdrivers.exe or dbxconnections.ini
(but you need to deploy the DLLs
specified in the LibraryName and
VendorLib, of course).
Also make sure to set LoginPrompt to
False and leave LoadParamsOnConnect
set to False, too.
BOUNTY AWARD
I have awarded the bounty to this answer as it was the one that pointed me away from investigation of the IDE, its installation and configuration, to investigation of the connection into the database.
END
DK about Firebird 64 bit - -no experience. But I've always had a lot of trouble with dbExpress. Never any problem with the included IB components suite. But there is a lot of confusion with IB versions...
But IMO you're best served using the ADO ('DBGo') components as opposed to any proprietary IB or Delphi specific drivers. What you need is an ADO provider for IB, available #:
http://www.ibprovider.com/eng/ - and as others have said, avoid using localhost, use 127.0.0.1, or better still, determine the true IP address of your workstation (ping machine-name...) And are you sure you don't have some kind of firewall or intrustion protection that may be involved?
You also need to make sure that your IB connection is configured properly - local or TCP, and no, don't use quotation marks for your names, pwrds, etc. The error message you got seems to indicate that you're trying to connect via TCP and it's not properly configured. What happened between the time it worked and the time it didn't work? Shut down Delphi? Reboot the machine? Explain please....
No 'special permissions' are needed - you simply need to ensure that your database server and client are properly installed and configured. In terms of functionality you can do everything with the pro version - just that the drivers etc aren't included in the package.
Again, IMO go for ADO and you'll never look back.
HTH,
MNG
Have you tried Paradox via the Borland Database Engine (BDE) and related components: TTable TQuery TStoredProc TDatabase and TSession?
If memory serves me correctly, at least as far back as Delphi 3, the distinguishing factor between "professional" and the "higher-level" editions has been the type of database development "out the box".
In Delphi 1, the BDE was the only way to do out-the-box database development.
Delphi 2 permitted a custom database layer by abstracting parts of the database component hierarchy.
Delphi 3 Professional provided BDE and drivers for file-based databases and Interbase.
One level up (Enterprise?*) they provided BDE drivers for typical client-server database access: SQL Server, Sybase, Interbase, Oracle,... (and native drivers for Interbase)
Another level up (Architect?*) introduced multi-tier development with Midas. Unfortunately, Borland took a step back with Midas, because the multi-tier components were again hard-wired to the BDE. (This was resolved in Delphi 4.)
?* Please note, I may be mistaken about the exact naming of these editions. Around about that time I formed the opinion that Borland was merely coming up with "grander" names in order to charge more for features that didn't really offer as much benefit as the 'big-cheque-writing-CIOs' came to believe - leaving developers to deal with the fallout. (Yes, I have battle-scars from Midas I.)
Rant aside, the theory was....
If one embarked on entry-level database development, you would purchase Delphi ?? Professional. Develop your system against a file-based database or Interbase via the BDE.
If you later needed to scale-up: you would upgrade Delphi, purchase your chosen SQL RDBMS, switch your connectivity via the TDatabase component, and apply the few necessary tweaks.
NOTE: In Delphi 3, you could switch to Native Interbase (personally not recommended) or use third-party components for non-Midas development. From Delphi 4 up, ADO and DevExpress started receiving more attention and nowdays, the BDE seems to be pretty much forgotten.
Of course theory & practice seldom frequent the same pubs. However, with a few cautionary pointers, you should be able to develop a significant file based solution that can be upgraded relatively painlessly.
Keep your business logic out of the database. This is quite possibly the biggest and most frequently encountered error. Huge chunks of systems are often written in triggers and stored procedures, making it more difficult to maintain or migrate a system.
Avoid platform-specific database techniques. This should go without saying, but if you don't explicitly look out for them, you will encounter problems.
Particularly relevant to file based database systems, many support special locking mechanisms - avoid them! They don't scale well to large multi-user systems in any case.
Generating of artificial keys often varies by platform: Generators, IDENTITY columns, how you get the new value.
Plan your system for large volumes of data. Identify the high-transaction tables, and avoid using uncontrolled retrieval of all records. I'd also avoid the TTable in this situation - BDE does a lot of interesting background things with TTable, and behaviour can vary according to driver and platform.
Disclaimer: All this was a long time ago, so some of the details may be a bit sketchy.
Disclaimer2: I don't have any experience with Delphi XE specifically. I currently use D5 professionally, and D2009 in my personal capacity.