RPC (remote procedure call is a common name), but what's the definition of procedure call ?
From https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf:
ASIDE: WHY SYSTEM CALLS LOOK LIKE PROCEDURE CALLS
You may wonder why a call to a system call, such as open() or read(), looks exactly
like a typical procedure call in C; that is, if it looks just like a
procedure call, how does the system know it’s a system call, and do
all the right stuff? The simple reason: it is a procedure call, but
hidden inside that procedure call is the famous trap instruction.
....
What is the classification? Are there other xxxx calls classification?
Procedures is just another name for subroutines/functions.
From source (emphasis mine)
In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction.
And source
Subroutines may be defined within programs, or separately in libraries that can be used by many programs. In different programming languages, a subroutine may be called a routine, subprogram, function, method, or procedure.
So, procedure calls are just calls to the subroutine/function. This invokes the steps laid out in the procedure.
From source
A procedure call is a simple statement made by stating the procedure name, listing actual parameter names or values within parentheses, and adding a final semi-colon.
Related
I've put together a FiveM server using alot of public code and discovered there are cheat systems out there that allow the user to corrupt or delete the underlying database. The reason is because they can inject Lua scripts which can contain DROP, DELETE INSERT and UPDATE and if they know the schema potentially could do whatever they like.
My intention is to deny access to every command except for SELECT and move all the other logic to stored procedures. The thing is that the user executing the proc will be the game user account which if locked out would also be blocked server side? Am I able to deny access from calling applications but allow access from within a stored procedure or have the procs execute as a different account vs the normal SELECT statements? Are there any other considerations or designs that could work? I'll be using parameters across all calls to help guard against injection, but I'm fairly new to MySQL so wondering what other steps people take for these scenarios.
Yes, you can give the MySQL user privilege to call procedures only. Then the procedures execute with the privileges of the user who defined the procedure.
Read https://dev.mysql.com/doc/refman/8.0/en/create-procedure.html the parts about SQL SECURITY which has choices DEFINER or INVOKER. The default is DEFINER, which is what you want.
However, you would also need to deny SELECT privilege to the app user. A malicious user can cause problems with nothing but SELECT privilege. They can't change data, but they can overload the database server.
So you'd need to implement every database query, both reads and writes, in a collection of stored procedures.
Here's an alternative suggestion: Allow the app to work as it does today, where the app connects using its username and does SQL queries directly.
But if the user wants to invoke their Lua script, only allow that on a separate database connection, using a different MySQL user with limited privileges. Basically only the EXECUTE privilege on a specific schema. You can implement a set of stored procedures that the Lua script is allowed to run, and put them in that schema. Then Lua scripts cannot do other tasks that the app does, a Lua script can only run the finite set of procedures you want to allow them to run.
When sp_recompile is run against a table, I understand that all stored procedures and triggers dependent on that table will be recompiled.
What I don't understand is what parameters SQL Server uses for this recompile. I can't see how parameter sniffing would factor in here. Does it compile an execution plan that is 'generic' using something similar to OPTIMIZE FOR UNKNOWN?
I feel like I'm missing something really obvious.
Does anyone have an understanding of this?
sp_recompile do not executes a recompilation of the objects itself. It deletes only all saved execution-plans. This forces an recompilation by the next call of the object (with the parameters of this next call).
How to handle transaction within a scope using Enterprise library. I've 3 stored procedures, which I need to execute in a single scope. I dont want to use System.Transaction name space
You can call the BeginTransaction method on a connection object to get a DbTransaction object. Then use the Entlib Database object's overloads that take a DbTransaction. However, it's a giant pain to manage. You'll need to create and close least one connection manually rather than relying on Entlib to do the right thing, and you'll have to pass the DbTransaction object around to everything that needs it.
TransactionScope really is the right answer here. If you've got some blocking scenario that really prevents you from using it that isn't some brain-dead corporate policy, I'd love to know what it is.
Where I work it is a requirement for us to go through stored procedures as a mechanism to access our data through code. I am using LINQ2SQL to minimize this pain so that I can work with objects instead of ADO.NET directly. I have a situation Linq2SQL is consuming one of my stored procedures an generating code where the return type from the stored proc call is an int. The stored procedure actually returns a dataset. After doing a little research I have found that this is because the SQLClient library can not properly parse the sproc to generate the expected metadata that Linq2SQL uses to create the object graph. My question is how can sprocs (even complex ones) be structured so that you get an object graph out of linq2sql, or in other words what should you avoid having in your stored procedure that will create confusion for the SQLClient library to not understand how to generate the metadata that linq2sql consumes in order to create an object graph?
This is not actually a limitation of LINQ to SQL but rather of SQL Server which can not always tell a client what the return type would be without actually running it when it contains temporary tables, cursors or dynamic SQL.
As running it with invalid parameters could be potentially catastrophic it doesn't try.
You can either set it by hand using the designer or if it is absolutely okay to run the stored procedure with invalid data (i.e. it is purely passive) then you can add SET FMTOPT OFF to the start of the stored procedure.
DamienG works on the LinqToSql team at Microsoft and I have upvoted his answer as correct.
That said, he likely won't advise you away from LinqToSql and I think it's very important to consider that option.
Trying to guess the return type of a stored procedure is very difficult and LinqToSql does it as well as anyone (for SQL Server). That said, there are very compelling reasons not to use stored procedures:
Stored procedures are bad, m'kay?
If you must protect your tables from developers for "security reasons" (which I'm guessing is the situation you are in), it's best to do that with views instead of stored procedures.
If you are using views, you then have a lot better options in the ORM department than LinqToSql.
The main problem you are going to run into with LinqToSql in this regard is that what works fine for 5 stored procedures in a tiny database doesn't work fine for 50 or 500 stored procedures. You can use the O/R Designer to "override" the return type of a stored procedure, but you will have significant syncing issues when stored procedures or the tables, etc. they operate on change. Changes to stored procedures will not get reflected in the O/R Designer unless you remove the stored procedure from the O/R Designer, re-add it, and then reapply your custom override. If your project is like any normal project, the tables and stored procedures change often and this sync issue soon becomes a nightmare because it's completely manual and if you fail to do it correctly you will get very strange errors at runtime.
I would strongly advise against continuing down the path you are on.
I know what I'm looking for is probably a security hole, but since I managed to do it in Oracle and SQL Server, I'll give it a shot:
I'm looking for a way to execute a shell command from a SQL script on MySQL. It is possible to create and use a new stored procedure if necessary.
Notice: I'm not looking for the SYSTEM command which the mysql command line tool offers. Instead I'm looking for something like this:
BEGIN IF
COND1...
EXEC_OS cmd1; ELSE
EXEC_OS cmd2; END;
where EXEC_OS is the method to invocate my code.
This isn't so much an answer to the question as it is justification for this sort of functionality - hence negating those who would say "you should do something else" or "why would you want to".
I have a database which I am trying to keep strict rules on - I don't want orphans anywhere. Referential integrity checks help me with this on the table level, but I have to keep some of the data as files within the filesystem (this is a result from a direct order from my boss to not store any binary data in the database itself).
The obvious solution here is to have a trigger which fires on deletion of a record, which then automatically deletes the associated external file.
Now, I do realise that UDF's may provide a solution, but that seems like a lot of C/C++ work to simply delete a file. Surely the database permissions themselves would provide at least some security from would-be assailants.
Now, I do realise that I could write a shell script or some such which could delete the table record and then go and delete the related file, but again, that's outside the domain of the database itself. As an old instructor once told me "the rules of the business should be reflected in the rules of the database". As one can clearly see, I cannot enforce this using MySQL.
You might want to consider writing your scripts in a more featureful scripting language, like Perl, Python, PHP, or Ruby. All of these languages have libraries to run SQL queries.
There is no built-in method in the stored procedure language for running shell commands. This is considered a bad idea, not only because it's a security hole, but because any effects of shell commands do not obey transaction isolation or rollback, as do the effects of any SQL operations you do in the stored procedure:
START TRANSACTION;
CALL MyProcedure();
ROLLBACK;
If MyProcedure did anything like create or edit a file, or send an email, etc., those operations would not roll back.
I would recommend doing your SQL work in the stored procedure, and do other work in the application that calls the stored procedure.
see do_system() in http://www.databasesecurity.com/mysql/HackproofingMySQL.pdf
According to this post at the forums.mysql.com, the solution is to use the MySQL_Proxy.