I don't know exactly how to word this question and I haven't been able to find any specifics on it so apologies if it's a duplicate.

I know that it's standard practice to have database server software run as a specific operating system user, with access to nothing but the necessary directories and files. I understand that this is done to prevent intruders that gain access through the software to have priveleges outside the minimum necessary for the db to run.

However, should I also restrict read and/or write permissions to the database directories and files at the operating system level to the db user alone? Is this standard practice? Are there any problems that can arise by other software or the operating system performing read operations on a live db?

I'm interested in both the general case (a live server, like a vps) and the case where it's running on a local desktop, used by only one person. Using postgres at the moment and I'm not experienced.

1 Answer 1


I'd say this is a good security practice to restrict OS access to your DB files. First you should definitely restrict write privileges to DB files at the OS level, if not already configured that way. Don't allow anyone other than the OS user that runs the DB to write to the DB files. Practically any DB software I can think of restricts this by default.

If you want to additionally restrict read access, this would be a good idea, especially if your database contains sensitive information. Any unprivileged OS user that shares your OS, if he/she has read-access to your DB files, they basically can get read access to your DB. They could simply steal copies of your DB files, send them to their own server, and setup the DB system and grant for themselves unlimited access to that clone. I'd say the majority of DB software does NOT proactively restrict read access at the OS level to the datafiles. It's up to you, the DBA to restrict this. If your data is super sensitive, you might want to consider encryption, which is available in most major DBMS. If the datafiles are encrypted, a would-be information thief would most likely be foiled even if he/she made off with your datafiles.

Don't forget to encrypt your backups, too, since they are just as sensitive as the DB itself.

Generally, you don't need to worry about the impact of cutting off access to other OS tools like backup software. Most DBMS can't and don't use any OS-based backup tools since DB files are changing. Rather you use specific tools like Oracle RMAN, SQL Server native backup, Litespeed, mysqldump, etc. These tools know how to handle a database that is changing and to get a proper backup. And some other OS tools like antivirus scanners run with root/system authority, so you can't keep them from reading your datafiles by permissions alone (encryption can).

If you're doing this on Unix, it can sometimes be a matter of simply chmod 700 (or perhaps 750) on the directory that contains your DB files. On Windows you could likely do this via NTFS permissions.

  • Thanks, this makes it clear enough. To summarize: restricting read access to db files is a good idea if you want to protect sensitive data but is not necessary at all if there is no sensitive data. In other words, there is no risk to db integrity unless you allow write access or suffer storage failures or software bugs, correct? Might want to add a tl;dr about this, just to polish the answer a bit - it's fine otherwise.
    – mechalynx
    Jul 6, 2015 at 22:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.