Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 578
  • Last Modified:

Why install SQL binaries on another drive

I know it's best practices to install SQL binaries on a non-system drive, but (the ugly truth), I don't know why. A client asked me and I'm er, uh...just because....

So why should SQL binaries be installed on a drive other than the OS as best practices? Google isn't giving up much.
0
barnesco
Asked:
barnesco
2 Solutions
 
didnthaveanameCommented:
I'm not going to lie - I always install the binaries on the system drive.  I believe the TempDB (all system DBs, for that matter) installs wherever the DBE is installed by default, which can be problematic if it expands to a point where it brings your drive down.  Beyond the concern that OS I/O causing disk contention that would impact SQL disk throughput, and the previously mentioned reason, I can't think of anything else.  Data and log files go on there own separate drives, definitely.
0
 
CluskittCommented:
One of the reasons is probably because the system drive is being read lots of times for the normal OS functioning. Having the DB on the same drive will cause SQL to compete for IO bandwidth with the OS (which has a higher priority), causing SQL related operations to lag on occasion.
0
 
Giovanni HewardCommented:
The primary reason is security.  If a vulnerability exists in your code (inadequate input validation) an attacker could exploit that condition via SQL injection and use path traversal to run local processes (such as the command interpreter in Windows), for example.  If your installing these binaries on your OS drive, an attacker needs only fingerprint your OS (IIS headers are revealing) to infer your OS paths and binaries... for example: ..\..\..\..\..\..\..\..\windows\system32\cmd.exe /c echo 0wned by G>>c:\apache\htdocs\index.php

Clearly this attack above couldn't be done if the process was running from another drive (X:), as the Windows directory won't exist off the root of X:, nor will the command interpreter.

An additional layer of security would be to explicitly deny all access to your OS binaries (execute, append, delete, etc.) from the restricted accounts used to run your webserver, interpreter, and SQL server processes.  You are using restricted accounts to run these processes, right? :-)

See http://www.blackhat.com/presentations/bh-europe-09/Guimaraes/Blackhat-europe-09-Damele-SQLInjection-slides.pdf
0
 
barnescoAuthor Commented:
The two answers above make perfect sense. Thanks.
0
 
CluskittCommented:
It might be a technicality, but I think the correct answer should be awarded to x66_x72_x65_x65 and mine should be only an assist. I feel his/hers is more accurate.
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now