In our software product, we want to add a feature that allows advanced users to define their own database views by entering any select statement they want, which will then be used in a "create view" statement.
While this is arguably dangerous in and by itself, are there any PostgreSQL functions that add dangers greater than "seeing everything in the database" and "overstraining the database by joining too many tables"?
I think of functions that would allow the execution of DDL statemtents, accessing the file system, executing commands on OS level etc.
Functions that are publicly available will be your least problem. All functions that can access the operating system are restricted to superusers and members of certain predefined roles like pg_write_server_files or pg_execute_server_programs.
Still, I think that this is a bad idea: anybody who can submit an SQL statement can easily launch a successful denial-of-service attack, either hogging the CPU or filling the disk with temporary files.
Related
I want to be able to use the variable names in Redshift which refers to my DB Objects (like schema and table names). Something like...
SET my_schema="schema":
SET my_table="table";
SELECT * from #my_schema.#my_table;
But looks like Redshift doesn't have such feature. Is there any workaround possible to achieve this?
There are a few ways you try to attack this. But first trying to use a database engine for functions beyond querying the database is a waste of horsepower and the road to db lock-in. So I'm going to focus on ways to do this before the database.
The most complete way is to use a front-end system that clients connect to and then this system in turn connects to the db. The one I've used in the past is pgbounce-rr which pools connections to the the db but also allow for modifications to the SQL before being sent on. This will do what you want but you will need a computer to perform this work.
If you use Redshift data-api you could put a Lambda function in series which performs the SQL modifications you desire (but make sure you get your API permissions right). However, I expect it is unlikely that you are looking to move to an API access model.
Many benches support variable substitution and simple replacements in the SQL can be done by the bench. However, this is very dependent on which bench you use and having all users' benches configured correctly.
Bottom line - if you want something to modify your SQL do if before it goes to Redshift.
I have developed an Excel add-in that I pitched to my employer's IT department. The add-in creates SELECT, INSERT, DELETE, and UPDATE SQL statements that are sent to a PostgreSQL database and any results (in the case of a SELECT statement) are returned to Excel to report on.
My team has been very impressed with this, but IT said that they don't allow laptops to perform CRUD operations directly on databases. Instead IT has set up certain environments to do this.
Can someone tell me if IT's concern around laptops directly connecting to a database and performing CRUD operations makes sense? Is this a valid concern?
If the laptops, their users and anybody else with access to them, the network connection, and the client software are all trusted, and you can always immediately push an update to the clients when the database structure inevitably changes in the future, then it's OK.
Otherwise it's not. The standard way would be to put some kind of service between the two that acts as a gatekeeper and defines the allowed operations on the database and who is allowed to do them. REST (or if you're enterprisey, SOAP) are two popular options. And don't send SQL over the wire in those cases.
With some database engines it might be possible in theory to let the users directly authenticate with the database and use the database's permission model to limit what they can do. For instance you could only allow users to execute certain stored procedures. But in practice that's probably more trouble than it's worth.
To be honest in practice it's probably not OK. That's too many things to trust at once.
Yes this is a valid concern. Someone could easily inject an SQL command into your database. They might be able to perform an operation that erases the entire database.
Say your software has this coed into itself: "SELECT $var1 FROM TEST WHERE $var2" and the user can modify var1 and var2. If they put "date > 10; DROP *" into var2 now your statement becomes "SELECT $var1 FROM TEST WHERE date > 10; DROP *;"
It is a little more complicated than that, but you should read up on SQL Injection.
Is it possible for firebirdSQL to run 2 servers sharing 1 database file (FDB)/ repository?
No. The server needs exclusive access to the database files. In the case of the Classic architecture version, multiple fb_inet_server processes access the same files, but locks are managed through the fb_lock_mgr process.
Databases on NFS or SMB/CIFS shares are disallowed unless one explicitly disables this protection. firebird.conf includes strong warnings against doing this unless you really know what you are doing.
If you mean if two servers on different host can share the same database, then no.
Firebird either requires exclusive access to a database (SuperServer), or coordinates access to the database by different processes on the same host through a lock file (SuperClassic and ClassicServer).
In both cases the server requires certain locking and write visibility guarantees, and most networked filesystems don't provide those (or don't provide the locking semantics Firebird needs it).
If you really, really want to, you can by changing a setting in firebird.conf, but that is a road to corrupt database or other consistency problems. And therefor not something you should want to do.
Every SQL server will not allow such configuration. If you want to split load, maybe you need to look at Multi Tier architecture. Using this architecture, you can split your SQL query load to many computers.
https://data.stackexchange.com/ lets me query some (all?) of
stackexchange's data/tables using arbitrary SQL queries, including
parametrization.
What program do they use to do this and is it published?
I want to create something like this myself (different data), but am
constantly worried that I'll miss an injection attack or set
permissions incorrectly.
Obviously, data.stackexchange.com has figured out how to do this
securely. How do I replicate what they've done?
This follows up my earlier question: Existing solution to share database data usefully but safely?
Our system will run on a local network with no more than 50 clients that connect to the same local server. We are creating a DB user for each client, to take advantage of the postgresql privilege system.
1) Analyzing the "performance", its OK to have ~ 50 DB users instead of reimplementing a custom system?
2) (SOLVED) How can the user check (what SQL statement) what permission he has in a table?
Solution:
SELECT HAS_TABLE_PRIVILEGE('user','table','insert')
I prefer to not reimplement the system, since a good security system isn't trivial to implement.
To answer the user/performance question: probably not. The only real risk would depend on how many users have unique security permissions (for example, if every one of those 50 users had different permissions on each table/schema in the database). In practice this should never happen, and as long as you have a sane group system for permissions, you should be fine.