I'm trying to write a script for a web portal (APEX) that allows a user to change their password on the associated database that they select
I'm trying to write a pl/sql procedure that I can execute over a database link to change the password on that database.
I guess what I am asking is can I connect as a different user within a PL/SQL block and run alter user identified by from within that block?
CREATE OR REPLACE PROCEDURE CHPWD
(
Database IN VARCHAR2
, Username IN VARCHAR2
, old_pw IN VARCHAR2
, new_pw IN VARCHAR2
) AS
BEGIN
/* Something like conn Username/old_pw here
then
alter username identified by new_pw */
END CHPWD;
Thanks!
The standard approach would be to have the procedure owned by a highly privileged user who can change any password, grant execute on the procedure to the users who should be able to execute it, and place logic in the procedure to implement security restrictions.
I believe the main issue is authenticating the user's password before changing it. I do not think there is a secure method to do this though - the best way to confirm the password would be to, as in your comment, login to the database with it. That requires passing the password to an external script though which would reveal your plain text password to anyone with access to the system.
The other method would be to take the algorithms that people have used to duplicate Oracle's password hashing algorithm - but this is effectively hacked together and liable to be changed:
http://www.petefinnigan.com/weblog/archives/00001097.htm
Related
In my database, i have one procedure which has been accessed by two other users through FID (outside of the database).
i need to log the FID of the user who are all using my procedure.
Is there any SQL Query to get the FID in oracle??
You didn't specify how exactly your users are identified (there is no "FID thing" in Oracle RDBMS).
Oracle knows only about two layers of identification:
Session user (for example scott#). This is how to get connected user:
select sys_context('userenv','session_user') from dual;
Proxy user (for example proxy[scott]#). This is how to get connected proxy user:
select sys_context('userenv','proxy_user') from dual;
If your user identification is happening outside Oracle, then you can't catch it in PLSQL. You should add another IN parameter to PLSQL procedure and pass it by your outside app when calling stored procedure.
My team have some problems with my database system assignment:
--- My team have already made a website, and we have register page in that clients must enter their information (include ID and password) to create an account
--- When clients finish register account step, my team must create an account from the ID and password that clients entered in Oracle (I mean after clients creating their account on our register page, we must synchronize it into our database in Oracle)
We have difficult at step "create an account from the ID and password that clients entered in Oracle"
Thanks you for reading my question
Well, the common practice for such a situation is to save the customer's ID and Password in some table and then check if the customer with the entered ID and Password does exist in the table on each login.
However, if your need is to create an Oracle User, you can use the procedure like that:
CREATE OR REPLACE PROCEDURE create_user(p_id VARCHAR2, p_password VARCHAR2) AS
v_sql VARCHAR2(100);
BEGIN
v_sql:='CREATE USER '||p_id||' IDENTIFIED BY '||p_password;
EXECUTE IMMEDIATE v_sql;
END;
An additional thing you should pay attention is the privileges that should be given to that user. For example, in order to be able to connect to database with his user, he should have a CREATE SESSION privilege. After defining the list of necessary privileges, you can add their grants to the procedure.
I have created a procedure in different database than the user used to create it,
The user I used to create the procedure is like 'vbhas' and the database it is created is like 'IFSRD', when I login as 'vbhas' and try to execute the proc it gives the error, could you please let me know how to modify the execute access so that I will be able to execute this procedure successfully?
Thanks
You have to add the SECURITY option. Depending on the SQL in the SP and your needs this might be SECURITY CREATOR|OWNER|INVOKER instead of the default DEFINER.
You should read the manuals for details
Thanks dnoeth...
Got to know that Teradata gives permissions at database level, so now I created the procedure in the database which has execute permissions to all objects.
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.
We are building a management app for our system, and one of the app's abilities is to create new databases for new users. This app needs to CREATE DATABASE, RESTORE DATABASE, CREATE USER, grant permissions, etc - so the user needs to have some very strong permissions.
We are contracting these services to an external company and we do not want to give them unrestricted access to our system, we only want them to be able to do what we allow them to do. So we thought about encapsulating the entire process in a stored procedure, granting EXECUTE on this to a specific domain user, and running it with EXECUTE AS 'SA'.
Unfortunately that is not possible - SA is not a database user and when we try to define it as one, we get the error
Msg 15405, Level 16, State 1, Line 1
Cannot use the special principal 'sa'.
We then thought about using DBO and setting up cross-database ownership chaining, but this is all beginning to be a serious headache.
Does anyone know of an elegant way to do this?
This is perfectly possible with module signing.
Create a procedure that executes the elevated code.
Add EXECUTE AS CALLER to the procedure
Create a certificate and private key
Sign the procedure
Drop the private key
Export the certificate
Import the certificate in [master]
Create a login derived from the certificate
Grant the required privileges to the certificate derived login
Note that any alteration to the procedure will invalidate the signature and will require to redo the procedure. Dropping the private key is very important because otherwise the vendor can sign a different procedure and get the elevated permissions on arbitrary code. See Signing an Activated Procedure for an example.
To manage things inside a database, you can use EXECUTE AS OWNER and make sure dbo owns the stored procedure. No problems there
However, CREATE DATABASE etc requires server level permissions. Note: you don't need sysadmin permissions.
With SQL Server 2012 you can use server roles, and GRANT CREATE DATABASE to this server role. For earlier versions, you can grant this directly to the login. Or use dbcreator if your prefer.
If you decide they need to manage logins however, securityadmin has the same effective permissions as sysadmin
create database admin;
GO
alter database admin set trustworthy on
GO
alter authorization on database::admin to [sa]
GO
use admin
GO
create procedure adminProc
with execute as 'dbo'
as
create database test
GO
create login tmp with password = 'tmp', check_policy = off
GO
create user tmp
GO
grant execute on adminProc to tmp
GO
execute as login = 'tmp'
GO
-- This fails
create database test
-- This works
exec adminProc
GO
revert
GO
drop database test
GO