Hello all I am trying to create an in instead of insert trigger which has the following syntax
create trigger HashPassword on PasswordTBl
instead of insert
as
begin
insert into PasswordTBl (PasswordProxy)
select HashBytes('MD5', '#!'+PasswordProxy)
from inserted;
insert into master.dbo.PasswordTBl1(PasswordProxy)
select PasswordProxy from inserted;
end
As pretty much clear from the trigger I want to store the hash password in original table and plain text password in backup table which is hidden from all user but the problem is anonymous user can know the secondary table name by checking the trigger.
I would be grateful if anyone can provide me a way to hide or encrypt this trigger or any alternate way to achieve the same.
Thanks in advance..
You cannot hide a trigger - but you can encrypt its source code, so regular users cannot see what's inside:
create trigger HashPassword on PasswordTBl
WITH ENCRYPTION
instead of insert
as
begin
......
It's a simple and easy protection - but also quite a weak one; there are ways to decrypt that source code again. It can keep away the sneaky employee, but certainly not a determined hacker....
Your users should not be able to read the trigger definition, even if they have rights to INSERT/UPDATE/SELECT. If they can, they have too many rights.
WITH ENCRYPTION only obfuscates the code from folk with rights already.
See GRANT VIEW DEFINITION: One, Two and Three. Note, this is implied by ALTER and db_owner rights.
One question: if someone can see the code, they can probably see your backup table... Even if it is in master the user requires rights there to write into the table because it is a different database.
If you haven't granted rights to the users or public in master, then this implies sysadmin rights. Which means someone can undo WITH ENCRYPTION easily
Lordy, this is wrong on so many levels.
Related
I am using SQL Server 2012.
I have a table which contains two columns. One is called Directory, the other UserName.
To explain my problem I think a simple example is easier.
So this table has 3 users. In the UserName column, only the 3 users, usernames can be entered plus one other entry called Default.
Directory UserName
C:\Blah Bob
C:\BlaF Brad
C:\BlaK Dave
C:\BlaPP Default
C:\Anoth Default
What I would like to know is if it is possible to allow only two of the users to be able to insert, delete records with the username Default and the other user to be able to only select the records with Default.
Is this possible?
Update
After doing some reading is it not possible to do this using an Instead of trigger? So in my understanding this trigger will fire before an insert, update or delete query is executed. So I was thinking in the trigger if could check the host pc (users on my team will only be using their computer) to see who it is trying to insert, update or delete and if its a user who doesn't have permission to edit the default list then exit the trigger and don't update the table. Or am I missing something?
Instead of giving users direct access to the table, give the first two users access to a stored procedure that inserts to the table, and only inserts "Default" for the username.
Give the third user access to a view (or stored procedure) that only selects records where username="Default".
I need to restrict user access to SELECT, INSERT, UPDATE and DELETE, so that user should manage data only using stored procedures I provide.
So, for instance
SELECT * FROM Table1
should return
The SELECT permission was denied on the object 'Table1'
however, if there is stored procedure SelectTable1 defined as
CREATE PROCEDURE SelectTable1
AS
BEGIN
SELECT * FROM Table1
END
(the real one contains filtering and parameters, so it is not meaningless, like the one above)
user should execute it successfully and get the resultset.
But obviously, I have no success implementing this set of permissions. Can anybody point me to some specific tutorial? MSDN was not very helpful.
Database is SQL Server 2012 and all objects (tables and stored procedures) are in custom schema.
You can do it using GRANT EXEC either on specific procedures or on schemas or on a database.
The following example grants EXECUTE permission on stored procedure
HumanResources.uspUpdateEmployeeHireInfo to an application role called
Recruiting11.
USE AdventureWorks2012;
GRANT EXECUTE ON OBJECT::HumanResources.uspUpdateEmployeeHireInfo
TO Recruiting11;
GO
Thanks to Igor I've got to the right MSDN page, and followed rights links.
However, using ownership chains suggested was too complicated for me, so I used
WITH EXECUTE AS OWNER
on my stored procedures and that works very good. When I log on using restricted user I see only procedures, no tables at all and I can execute procedures, but not even select from tables.
Also, I want to mention this concept is very similar to setuid and thus was familiar to me.
I mark Igors reply as answer, because ownership chains seem to be more generic way, just wanted to share info I found.
Hi Experts
How I can prevent database user deleting any data in tables using triggers?
I want just Admin delete Data from tables
Thanks
Umm take away that users permission? If you don't want them doing something, 'disallow' them that right... thats why we have permissions.
Here are details on how to revoke permissions:
http://msdn.microsoft.com/en-us/library/ms186308.aspx
Any particular reason you want to use triggers?
You could simply remove the DELETE permission from the users you want to restrict. Have a look at the "Permissions" section here: http://msdn.microsoft.com/en-us/library/ms189835.aspx
EDIT: Since you say you do want to use triggers (but I really think you should reconsider) you can create a table such as:
CREATE TABLE Restricted_Users
(
user_name VARCHAR(40) PRIMARY_KEY -- Use a size appropriate to your requirements
)
Create INSTEAD OF DELETE triggers on all your tables (that's going to be a chore) which checks for the USER_NAME() in the Restricted_Users table and if they EXIST you can call RAISERROR to cause the transaction to be rolled back and display a message to the user.
Remember you will have to maintain these triggers on all new tables added to the database as well as maintaining the list of users in the Restricted_Users table whenever you add/remove users from the database.
It would be a lot simpler to use the permission system available in SQL Server (it's what it's designed for) using roles with appropriate permissions set for the tables. Then, when adding new users you only have to assign them to the appropriate role and the delete permissions are handled for you.
I'm using mssql server 2008 and having a problem with a trigger. Now, i have this aspx page, which has a stored procedure working in a button click, and that stored procedure has an execute permission for the user, lets says "x". this procedure insert some values to a table on one db. and that table has a trigger for insert, which should insert those values to some tables at other databases.
As i said, the stored procedure has an execute permission for the user "x", and the same user have insert/update/delete/select permissions on the tables that the trigger should do the insert to.
But when someone with an "x" permission starts the procedure, he/she gets this exception message : Cannot find the object "DatabaseName..table_name" because it does not exist or you do not have permissions.
But i know that database and table name is correct.
So i am thinking, maybe it has something to do with the table having permissions but i am not sure of course.
Any help with be appreciated, thanks.
Maybe you have same tables with different schemas? Your message doesn't indicate schema used.
Or your user has not other database access right? It is actually possible that user has rights to table, but his access to database itself is disabled.
I am using Oracle Sql Developer
I have a huge script that creates tables, indexes, primary key constraints and such.
my DB name is: dbo_other
I logged into this dbo_other as sysdba.
If I run my script then tables do not show up on left panel under 'Tables'
However, if I append the script by adding 'dbo_other.' in front of every table name then the tables show up.
This is very tedious and time consuming.
Is there a way to avoid this? why wont they show up in dbo_other without adding dbo_other. in front of every table name?? When I run the query on the upper right corner the drop down has dbo_other selected!!
I can even do a select * from the table created (but dont see it in left sidebar) Furthermore, I can see the table in pl/sql developer.
Why does oracle sql developer want me to create it with dbo_other.??
Also, is there a way to avoid adding it for each table? maybe something can be done on top of the script so it takes effect on everything that follows?
Why are you logging in to your database using the SYSDBA account? This is very powerful, and it will allow you to do terrible damage to your database if you don't know what you're doing. In a development environment there's a limit to the harm you can do but it's best to get into good habits before doing things in Production.
The interesting thing about AS SYSDBA is that it overrides the username part of the login: if your OS user has the privileges, you're in. As SYS. Check it out:
SQL> conn apc
Enter password:
Connected.
SQL> show user
USER is "APC"
SQL> conn apc as sysdba
Enter password:
Connected.
SQL> show user
USER is "SYS"
SQL>
So, when you ran that script you created all those objects in the SYS schema. Which will prove to be a massive pain in the neck. I hope you have an equal and opposite reversion script.
To run the script properly, all you need to do is connect as DBO_OTHER (normal - i.e. without SYSDBA or SYSOPER which is the default after all). Your script will create tables in the current schema.
If you need to create objects in several schemas, you don't need to log out and in again. The schema is distinct from the user and it is possible to switch schema by executing alter session set current schema = WHOEVR;. This is quite a handy trick and I blogged it up some time back. Find out more.
Note that your user will not acquire any additional privileges by changing the current schema: they will only be able to do what they currently can do. So for something like creating objects in multiple schemas the executing user should be a power user, somebody with CREATE ANY privileges such as a DBA (but still not SYSDBA).
I just stumbled upon this little jem which lets you perform actions on a schema/user by default for which you are not logged in as. That is, by default your select statements, etc will operate on this new schema instead of your own.
alter session set current_schema =
Example:
Myself
+ table1
+ table2
SomeoneElse
+ SuperTable1
+ SuperTable2
log in as "Myself"
select * from SuperTable1
Error: ORA-00942: table or view does not exist
alter session set current_schema = SomeoneElse
select * from SuperTable1 <This will work.>
The "Tables" tree on the left-hand panel only includes tables the logged-in user owns in Oracle SQL Developer. If your script creates tables in another user's schema, you need to click the + next to "Other Users", find the appropriate user, and click the + on their tables.
As others have said, you shouldn't use SYSDBA unless you need to, and it sounds very much like your script should be executed as a normal user based on its rough description.