I am using Redshift cluster. One user can rotate his own password using below command:
testcluster=> select current_user;
current_user
--------------
u003
(1 row)
testcluster=> alter user u003 with password 'Newpassword123#';
ALTER USER
How to stop this self password rotation. It must be rotated by super user only.
Is there any way to achive this ?
PostgreSQL allows users to change their own passwords.
See: ALTER USER documentation
Therefore, you cannot prevent users changing their own password.
Related
I have created two new users and a new role. Given select privilege to the role for one table in schema A and assigned this role to user b. While issuing a select query for the table in schema a with this user I am experiencing table or view not found issue.
CREATE USER READUSER1 IDENTIFIED BY readuser1;
CREATE USER READUSER2 IDENTIFIED BY readuser2;
CREATE ROLE READONLY_USER IDENTIFIED BY readonlyuser;
GRANT select ON READUSER1.TESTA TO READONLY_USER;
GRANT READONLY_USER TO READUSER2;
Now from READUSER2 session :
SELECT * FROM READUSER1.TESTA > 00942. 00000 - "table or view does not exist"
I assume that you created the table successfully in the readUser1 schema though you don't show that step.
When logged in as readUser2, what roles are enabled for the session?
select *
from session_roles
I'll wager that the role is not enabled for the session. Normally, you don't set passwords on roles because you normally want those roles to be available to the user as soon as they log in. If you set a password on a role, however, then every time the user creates a new session, they have to explicitly enable the role by specifying the password. That's quite useful in some unusual situations but it's not the norm.
Assuming that readonly_user does not appear in session_roles, you can enable the role using the set role command
set role readonly_user
identified by readonlyuser;
Once you've done that, the role should appear in session_roles and you should be able to query the table.
Normally, though, you'd have created a normal role not a password protected role by omitting the identified by clause
create role readonly_user;
I created a read only user in PostgreSQL using the command line by:
CREATE USER xyz WITH ENCRYPTED PASSWORD 'xxx';
GRANT SELECT ON DATABASE mydb TO xyz;
In order to delete this user, what's the difference between
DROP USER xyz;
and
DROP ROLE xyz;
There is no difference. From the docs:
DROP USER is simply an alternate spelling of DROP ROLE.
Hi: I have an interesting problem that needs a clever solution :-)
PG 9.6.5 on RHEL6_64
Constraints I have to live with:
- I'm not a superuser, but I do have createrole.
- Password is required for login
Let's say I have a table called "approvals"...
create table approvals (approval_id text);
And another table called "granters"...
create table granters (linux_uid text);
I need a perl/DBI script that must allow all users select, but only those linux_uids in the "granters" table can insert/update/delete into the "approvals" table. But when someone who is in the "granters" table runs the perl script, I do not want them to have to enter a password. The perl script can validate that an authorized user is running it using 'getlogin' and that's good enough.
I can create roles for the granters and grant them select/insert/update/delete on the "approvals" table, but they'd have to enter a password to log in first (one of the constraints on the DB is that pawwsords are required). So I can't see how this traditional method would work.
I could create before insert, update and delete triggers that can check the id of the person running the perl script against the list of uids in the "granters" table, then allow/reject the attempt on that basis. But I can't pass the linux uid into the stored procedure associated with the trigger(s). Something like perlplu might allow me to sniff out the linux uid, but again, I'm not a superuser, so (I believe) I can't create something like that.
Any ideas ?
Thanks in Advance !
Users are authenticated before any permissions inside the database are checked, so you cannot do that just within the database. Also, since you need to do something outside the database, you need superuser privileges.
First, if I were you, I'd rethink that requirement. It looks complicated and cumbersome; there should be a better solution.
You could use trust or ident authentication for password-less authentication, but you cannot make that dependent on the contents of a table in the database. It is governed by the pg_hba.conf file.
So what you'd have to do is to create a trigger on the table that runs with superuser privileges through SECURITY DEFINER and edits (and reloads!) pg_hba.conf whenever the table is modified. This is complicated, error-prone and dangerous.
I’m developing a web based application with PostgreSQL as the back End Database & perl handling the scripting
I hold the login info in a separate file similar to advice here where to store global database connection parameters so depending on what the script needs to achieve it could point to different login credentials Currently it’s the default PostgreSQL account this obviously needs changing.
I need to get my head around how to set up user accounts in PostgreSQL
I think I need two one that allows users to query the Database eg web_user the other will need to submit changes eg web_admin.
The web_admin account will need to log into the webpage
In pgAdmin or on the command line how do I create the login Rolls and give the what ever the required permissions are?
EDIT Please Clarify
I’ve had a stab at creating two accounts but am unclear if this is correct way to do it
CREATE USER web_user PASSWORD 'password1';
GRANT SELECT to web_user on Table1; // Read Only
CREATE USER web_admin PASSWORD 'password2';
GRANT SELECT,INSERT,UPDATE,DELETE to web_admin on Table1; // Read Insert and update / delete rows within a existing table but not able to create, alter or delete a Table or column
Edit 2 ooops
So I’ve executed the following in pgAdmin window
CREATE USER web_user PASSWORD 'password1';
GRANT SELECT to web_user in schema PUBLIC; // Read Only
CREATE USER web_admin PASSWORD 'password2';
GRANT SELECT,INSERT,UPDATE,DELETE to web_admin in schema PUBLIC
The web_user account allows just read access to a database the problem the web_admin account has the same read access
I’ve tried drop web_user & revoke by
revoke all privileges on database mydb from web_admin;
but it fails with errors about dependencies listing all tables in mydb
I've attempted to see what privileges web_admin actually has but have been unable to.
How do I drop this account
What is wrong with the syntax for grant web_user?
To create users you can use CREATE USER command in SQL. (it is the same as CREATE ROLE ... WITH LOGIN) Afterwards you use GRANT to grant privileges.
I'm not sure what you mean by "default PostgreSQL account". If you are talking about "postgres" account, it's superuser, and has rights to everything.
The topic of privileges, and securing is quite complex, I wrote about it at least couple of times:
How to grant privileges on all tables in PostgreSQL < 9.0
How to grant privileges on all tables in PostgreSQL > 9.0
How to secure your database
When I try to alter a table from a different owner in Firebird I got this error:
unsuccessful metadata update
MODIFY RDB$RELATION_FIELDS failed
no permission for control access to TABLE TAGS
I had already granted ALL privileges to this user, also REFERENCES privileges, but I still getting this error.
Does anybody knows how to solve this?
I use Firebird 1.5
Thanks
The Firebird 2.5 Language Reference section on ALTER TABLE states:
Only the table owner and administrators have the authority to use
ALTER TABLE.
In other words if you are not the owner of the table, you need to either login as SYSDBA, or you need to be logged in as root or Adminstrator on the machine with the database. There is - as far as I am aware - no other way to alter a table as a different user.
In Firebird 2.5 there is also the RDB$ADMIN role which allows a user which is granted this role to act with the same rights as SYSDBA.
The rights you can GRANT (except for REFERENCES) are only for DML, not for DDL operations.
Firebird 3 introduced metadata privileges, which allows you to grant these permissions to a specific user or role for specific object types.
For example:
GRANT ALTER ANY TABLE TO Joe;
Will allow the user Joe to alter any tables in the current database.