I need to grant access of existing login into my database and change password of other login from a T-SQL script that is run from C++ update program in transaction. It should run against SQL Server 2000 and also against any newer SQL Server version.
CREATE USER FOR LOGIN and ALTER LOGIN WITH PASSWORD are not supported in MSDE and SQL Server 2000 but I'm not able to use sp_grantdbaccess and sp_password either because they fail with error -2147217900
That I think is caused by the fact that these stored procedures cannot be run from user transaction and it can also be deprecated in future SQL Server versions.
Can you suggest any other solution?
Below is the sample of the script that is run in user transaction
CREATE PROCEDURE [dbo].[_PasswordChangeSaveCleanup]
#Meno varchar(50),
#HesloEncrypted varchar(50)
AS
BEGIN
...
return 1
END
GO
--CREATE USER [some] FOR LOGIN [some]
EXECUTE sp_grantdbaccess #loginame='some'
GO
GRANT SELECT ON [dbo].[UZivatelia] TO [ese]
GO
--ALTER LOGIN SOME2 WITH PASSWORD='vreK.BH45'
EXECUTE sp_password #new='vreK.BH45',#loginame='SOME2'
GO
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[SOMESP]') AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[SOMESP]
GO
Related
I'm really stuck with the following problem.
At GCloud SQL I have a running postgres' instance.
That instance contains two databases. From one database (source_db) I want to access to another database's (another_db) table (foreign_table) using postgres_fdw extension. The recipe I'm employing currently is this:
1)
CREATE EXTENSION postgres_fdw;
CREATE SERVER foreign_db
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (dbname 'another_db', port '5432', host '<A_PRIVATE_IP>');
CREATE USER MAPPING for guest
SERVER foreign_db
OPTIONS (user 'guest', password 's3cr3t');
CREATE FOREIGN TABLE foreign_table
(
// columns descripions
)
SERVER foreign_db OPTIONS (table_name 'foreign_table');
-- Alternatively I also tried with
CREATE SCHEMA external;
IMPORT FOREIGN SCHEMA public from SERVER foreign_db into external;
GRANT SELECT ON TABLE foreign_table TO guest;
The above commands runs without error, but when I tried to actually access the table I got this:
If using "external" schema
source_db=> select 1 from external.foreign_table limit 1;
ERROR: permission denied for relation foreign_table
CONTEXT: Remote SQL command: SELECT NULL FROM public.foreign_table (*)
If not using "external" schema
source_db=> select 1 from foreign_table limit 1;
ERROR: permission denied for relation foreign_table
CONTEXT: Remote SQL command: SELECT NULL FROM public.foreign_table
The only thing that smells a little is that the error message (at *) displays "public.foreign_table" instead of "external.foreign_table" even when I'm using external schema... but i don't know is that actually means something :S
As far I researched there is no way to login into the posgres instance as a superuser as that is not allowed by the Gcloud's SQL services neither a way to edit the pg_hba.conf file in order to adjust client's authentication affairs.
I searched in a lot of places but without finding what i can do to sort this out. Among the sites and pages i looked are the below list
The official documentation
A personal blog's post
This other SO post having a related issue
This post and this other post regarding permissions and authorizations.
A Nice tutorial about authentication and authorization
P.S.
I was able to make this on a postgres' instance that i ran locally.
User guest on the remote server doesn't have permissions to SELECT from the table. Since the query on the remote server is executed as user guest, you get an error.
GRANT the SELECT privilege on the table on the remote server to the user.
I'm using SQL Server 2008.
There is a Procedure ...
CREATE PROCEDURE xxx WITH EXECUTE AS OWNER
AS
BEGIN
SET NOCOUNT ON;
TRUNCATE TABLE ttt;
INSERT INTO ttt
(
field
)
SELECT
order_number
FROM
OPENQUERY([sss], 'SELECT ...')
END
... the Owner User can execute the procedure without any issue.
My Expectation was, if I grant execution access to some other User the other user should also be able to run this procedure.
But using the other Account a error is received: 'Access to the remote server is denied because no login-mapping exists.'
Actually I try to avoid giving the 'other User' full access to the linked Server.
User must be mapped to db_owner group
Extracted code from documentation,
create table sales_catalog(
item_id varchar(10) not null primary key,
item_name_desc varchar(50) not null,
item_desc varchar(50));
Error after using SYSDBA as the user in Firebird SQL3.
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
CREATE TABLE SALES_CATALOG failed
There is no privilege for this operation.
I did some experimenting, and the problem seems to be that if you connect to a database using ISQL without specifying a host name, it will use Firebird embedded to connect to the database (previous versions of Firebird didn't do that on Windows).
Firebird embedded does not require a username and password as it assumes that if you have direct read/write access to the database, that you are allowed to connect to it.
When you connect without specifying a username and password (eg using connect 'database.fdb' instead of connect 'database.fdb' user sysdba, Firebird embedded will use your OS username to connect.
This can be checked because ISQL reports the username when connecting:
SQL> connect 'd:\data\db\fb3\dbofnormal.fdb';
Database: 'd:\data\db\fb3\dbofnormal.fdb', User: MARK
Firebird 3 added new metadata privileges, for example creating a table in a database now requires that you are either the owner of the database (the username used in the create database statement), sysdba (or another admin user), or that you have the create table privilege. See also User Privileges for Metadata Changes. In earlier version any user would be allowed to create tables once they had access to the database.
Now on to the problem: the user (in my example MARK), does not have the create table privilege, so attempting to do so will fail:
SQL> create table testmark ( id integer generated by default as identity primary key);
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-CREATE TABLE TESTMARK failed
-There is no privilege for this operation
There are a few ways to solve this:
Specify a user with sufficient privileges in the connect statement (eg sysdba):
connect 'database.fdb' user sysdba;
Include the host name in the connect statement to connect through Firebird server instead of Firebird embedded, so that you are required to specify user name and password:
connect 'localhost:database.fdb' user sysdba password 'masterkey';
Connect once to your database as sysdba (see first item), and give the necessary privileges to the user (in my case mark):
grant create table to user mark;
From this moment forward this user can create tables (you may need to grant additional privileges, eg create view, create procedure, etc).
We got a Postgres database credentials (with SSL on) from our contractor, which allow us to connect to the DB using pdAdmin 3. The DB is read-only (can't do pg_dump) to us and basically the contractor will not grant us more privileges.
We need to fetch some data from this remote DB to our local DB. So I wanted to use dblink to perform this task.
I run this on psql:
insert into shifts select * from dblink('hostaddr=remote_addr port=9000 dbname=production user=user password=passwd', 'select user_id, location_id from shifts') as t1(user_id integer, location_id integer);
Then I got:
ERROR: password is required DETAIL: Non-superuser cannot connect if
the server does not request a password. HINT: Target server's
authentication method must be changed.
Since I am new to Postgres and dblink, I have no idea why it is complaining there is no password. And I wonder, to do a dblink connection, does the remote database needs to grant any more privileges?
If the pdAdmin 3 is able to connect to the remote DB with the credentials, what should I do to make dblink work?
Thanks!
Yes only superuser can provide you to the facility to connect through DBLINK
just run this command below whether you are able to connect to database
SELECT dblink_connect('myconn', 'dbname=postgres');
SELECT dblink_connect('myconn', 'hostaddr=remote_addr port=9000 dbname=production user=user password=passwd');
just give the name of database u want to connect after dbname
You can connect
dblink_connect_u
dblink_connect_u() is identical to dblink_connect(), except that it
will allow non-superusers to connect using any authentication method.
Link on postgres site is
dblink
For Superuser ask them to create extension
CREATE EXTENSION dblink;
for your database or schema .
I have postgres 9.3 being installed with my windows desktop app on computers all over the place. I don't want Joe Script-kiddy looking at the pgpass.conf, getting the postgres password a running amuck in my Database.
I was able to to make a backup role using this article but I ran out of luck with reindexdb and Vacuum Analyze.
So far my solution is to write an application that will take an encrypted vbscript file and use ado to connect and run.
I've read over the PG help on grant and role and I just can't see how to do this. I'd appreciate any ideas.
Neil McGuigan suggestion worked for reindex and analyze. I need to reindex each table in a loop though. If I try just to reindex database myDb I get EINDEX DATABASE cannot be executed from a function or multi-command string. I get the same error with vacuum [table]
I'm still playing around with dblink as a possible solution.
.. Well I can't use dblink because it wants the password so I'd have to code the password into the function and since my backup role has select it can view the contents of the function.
So I've got a low privileged role, backup, that can backup, analyze and reindex but cannot vacuum. seems strange to me.
You can always wrap the command in a function. Run the function with its definer's privileges. Give execute privileges to someone else. Example:
set role roleThatOwnsTable1;
/*
SECURITY DEFINER tells Postgres to run the function with the privileges of the role that
defined the function, as opposed to the privileges of the role that invoked the function.
*/
create or replace function reindexTable1() returns void SECURITY DEFINER language plpgsql as $$
begin
reindex table table1;
end $$;
grant execute on function reindexTable1() to someGuy;
set role someGuy;
select reindexTable1();
This does, of course, open that functionality to someone that should normally not have it, so be careful.