New answers tagged privileges
The documentation about ALTER DEFAULT PRIVILEGES tells you a possible reason - it is not that clearly described, though. Let's see, what is said: You can change default privileges only for objects that will be created by yourself or by roles that you are a member of. This means that the default privileges defined by this statement applies only to ...
I am not sure of any other alternative but i believe user needs to be there in MSDB or should have the admin rights to execute or perform any required action on the job. There is a connect item about this as well, SQL2005 SQLAgent MSDB security roles Or you can use an option as mentioned here: You could create a stored procedure that runs the job. You ...
Unquoted identifiers in SQL are implicitly converted to upper case, so the statement create view remotetabletest creates the view named 'REMOTETABLETEST', not 'remotetabletest'. In other words, the following should return the expected result: select * from user_tab_privs where TABLE_NAME = 'REMOTETABLETEST'
Yes that's possible. Create the function with the user owning all those tables and use the SECURITY DEFINER modifier. SECURITY DEFINER specifies that the function is to be executed with the privileges of the user that created it. create or replace function foo() returns void as $body$ ... $body$ language plpgsql security definer; Also see the ...
You need to grant EXECUTE on package itself. If security is your main concern you may create a new package that has just types, but you cannot specify that a given user can access only some objects defined in package specification - either all or none.
I'm not sure how much scope you have to make changes but why not separate the 2 concepts.? Have a field or flag on the user table has_voted. And put the vote in a separate table. App logic checks to see if they have voted, and only allows them to vote if the field is blank. Vote gets inserted in separate table so you can't tell who has voted for what.
How about encrypting the vote using a key that only the user and/or the system knows? Adding some more information: Use a symmetric encryption so that you can decrypt it. Encrypt outside the database. Do not use database encryption functions if you want to protect it from DB admin because admin has several ways to snoop into the queries and read the keys. ...
Every schema must have an owner, which is a database principal (user or role) within the database. The significance of the schema owner is that the owning principal has full control permissions. Also, objects within the schema inherit the schema owner by default so the owning principal typically has control permissions on all database objects within the ...
It is impossible to do this using permissions only . The only way is to create a stored procedure as described here If you want to avoid stored procedures, a workaround is: GRANT ALL PRIVILEGES ONtestuser_%. * TO 'testuser'@'%'; (as suggested here); however, this has the problem that the users must then be very careful in naming their databases. For ...
Top 50 recent answers are included