Tag Info

New answers tagged

0

Finally I've found the source of those permissions: This AD user had an "orphan" user in database with higher permissions than AD group. So in order to connect to instance this user needs to be a part of the group But after the connection he can get permissions directly from his "orphan" user in DBs Even if the group that he is a part of is only public group ...


0

Login as the mystery user. Then run: select * from sys.login_token Somewhere in the output list will be token that grants you access. For instance you can try this (not guaranteed to work): select * from sys.login_token lt join sys.server_principals sp on sp.sid = lt.sid;


0

afaik, this is not possible. However, as an workaround you can create function which makes count(*) under required schema and grant execute on this function to user. User will not be able to access table, but will get required count.


0

This happened to me when I upgraded our SQL Server from 2008R2 to 2014. db_datareader or db_datawriter or their deny equivalents perfectly work fine in 2008R2 but they doesn't work in 2014. Example to grant permission in SQL Server 2014 If you want to give user Alice the SELECT, INSERT, UPDATE and DELETE permissions to all table-valued objects in schema ...


0

Apart form all the DOs and DONTs about using SYS in this case is that "if you connect as sysdba, your schema name will appear to be SYS". Phil's answer demonstrates it. A nice quote by Thomas Kyte on a similar question - In general, unless the documentation tells you, you will NEVER LOG IN as sys or system, they are our internal data dictionary ...


-1

I'll start my answer with this: As a general rule: Never, ever, create objects as the user SYS/SYSTEM (or any other "internal" Oracle user) unless directed to do so by Oracle support. A simple test case shows that there's a big difference, due to ownership. As SCOTT: SQL> create table a ( b number ); Table created. SQL> create index a_idx on ...


5

May not be pretty, but you could use a trigger on database creation that executes as a privileged user of your choice: CREATE TRIGGER [database_setup] ON ALL SERVER WITH EXECUTE AS 'privuser' FOR CREATE_DATABASE AS BEGIN SET NOCOUNT ON DECLARE @db nvarchar(100) DECLARE @sql nvarchar(MAX) DECLARE @data XML SET @data = ...



Top 50 recent answers are included