Could someone guide how to create following profile define rules in EDB Postgresql:
count failed login attempts
lock an account due to excessive failed login attempts
define rules for password complexity
define rules that limit password re-use
I assume you confuse Oracle profiles:
https://docs.oracle.com/cd/B19306_01/network.102/b14266/admusers.htm#i1007119
with PostgresEDB roles:
https://www.enterprisedb.com/docs/en/10/pg/user-manag.html
which have no profiles...
What you could check instead is postgresql role as is:
https://www.postgresql.org/docs/current/static/sql-createrole.html
CONNECTION LIMIT and VALID UNTIL are somewhat similar to Oracle profiles, but also they are very different - worth of reading
Related
I am trying to setup Postgres 9.3 on an Ubuntu 14 server, and I'm feeling pretty demoralised at this point. I've previously used MySQL, so I'm happy with general database concepts, as well as client/server models etc.
I start with two users - 'root' and 'sam' (me). As 'sam' I install postgresql using apt-get. This also creates a third user called 'postgres'.
Fine.
I'm told that to use postgres you must be logged in as the postgres user, so I switch to that account. Apparently this comes with a postgres admin role (I think I'm fine with the concept of roles per se), and apparently all roles have an associated database of the same name (?). So now I have a Linux account called postgres, a role called postgres, and a database called postgres? This all seems needless but I'm assuming it's useful for reasons I don't know about (not meant sarcastically - this is usually the case when things seem overly complicated at first).
So, to create a database, do I login to the server as postgres, start postgres by typing 'psql' (which doesn't ask for a password - why doesn't the postgres account have a password?) and proceed from there? Or should I create a new role? Does that role need its own Linux user? Should the role be the same name as the database I want to create?
I appreciate this is a bit of a jumble, but my confusion is such that I'm not even sure I understand the fundamentals here. I miss MySQL.
I've been mainly using the DigitalOcean tutorial for this - which are usually very good - but it didn't really make any of this clear. I also read the postgres docs (specifically the installation and users/roles sections) which didn't help, and the google results for this are even less helpful.
This is my last hope before I go back to the safety blanket of MySQL. Any suggestions for making this click?
OS usernames and Postgres DB usernames are not related; they live in seperate universes.
one exception: if you connect from the same machine via the unix-domain socket, and you don't explicitely specify a username, your OS name is assumed to be your DB-username, too. (which in most cases is not correct)
second exception: the "postgres" username is used both as an OS-username (owner of the files, uid of the running processes) and as the DBMS superuser.
Note: "root" is a bad name for a DB-user.
I'm trying to deploy Mantis BT on Heroku, using PostgreSQL as the database, as a proof of concept and learning exercise (or perhaps more accurately, as a "climb up a steep learning curve," since I'm a total newbie to all three technologies).
The deploy of the PHP app to Heroku went fine, and accessing the app's URL brings up its admin/install.php page. Provisioning the PostgreSQL database went fine, and gave me a database URL that (obfuscated) looks like this:
postgres://useruseruser:passwordpasswordpassword#ec2-107-21-219-201.compute-1.amazonaws.com:5432/dbnamedbname
I'm able to access the database via psql using those credentials, and the user (predictably) doesn't have the 'usecreatedb' privilege. I can't really make sense of the output of the PostgreSQL \z command, which seems to say I have no privileges on a table I've created:
dbnamedbname=> \z foo;
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
--------+------+-------+-------------------+--------------------------
public | foo | table | |
(1 row)
but I put that impression down to not really knowing PostgreSQL's idioms yet.
Empirically I've been able to determine that I have the privileges CREATE (for both tables & indexes), SELECT, INSERT, UPDATE, DELETE, ALTER and DROP, which seem to be what Mantis BT requires for its "high-privileged database account."
So, it would seem that I have everything I need to fill in the Mantis BT admin/install.php form:
Hostname: ec2-107-21-219-201.compute-1.amazonaws.com
Username: useruseruser
Password: passwordpasswordpassword
Database: dbnamedbname
Admin Username: useruseruser
Admin Password: passwordpasswordpassword
Two notes here:
Yes, I know the regular DB user should not have all the privileges the Admin user has, but Heroku has only given me one DB username, and (because this is for now just a proof of concept) I didn't want to start down a possible blind alley of trying -- and failing -- to create a second user just yet.
The Mantis BT form says that the Admin username and password are "to create Database if required." Since the database ("dbnamedbname") already exists, I initially thought I could leave these blank, but Mantis BT insists on having values for them (and the install documentation says that if they are not supplied, "the database user will be used").
Yet, when I fill in the form using the values above and click the "Install/Upgrade Database" button, I get a failure indicating that the app could not connect to the database with the credentials provided (the exact same credentials, BTW, that I used to connect to the database using psql):
(One suspicious thing in the above screenshot -- that I haven't yet steeled myself to go hunting for in the code: the obscured Admin password in the page returned by the form submission only shows six bullets, whereas the actual password I pasted was 30 characters long.)
So, questions to anyone who understands how Mantis BT database setup works.
Is it actually passing only six characters worth of password to the DB server, or is that just a UI glitch?
Even after I figure out why it's not connecting to the database -- if that's really true -- is the notation "to create Database if required" (on the Admin username and password entries) really significant? Or will the silly thing go and try to create the database even though the specified database already exists?
If the answer to 2 above is "Yes, it will try to create the database anyway," what's the recommended way to work around that, given how Heroku goes about provisioning PostgreSQL databases?
The "Database connection failed" results from an initial connection attempt in which no database name is specified.
Attempting to access the server in this way from psql causes the following error:
$ psql -h ec2-107-21-219-102.compute-1.amazonaws.com -U useruseruser
Password for user useruseruser:
psql: FATAL: database "useruseruser" does not exist
Adding the database name as an additional parameter to that Connect() call causes the connection attempt to succeed, and thereafter all table creation steps and checks succeed.
It's not clear to me whether the problem is with PostgreSQL 9.4.5 per se, or whether it's something in how Heroku in particular configures their PostgreSQL servers.
Issue filed: https://www.mantisbt.org/bugs/view.php?id=20589
So, with the code patched, the answers to the questions I asked are:
It passes all parameters as entered, no truncations.
It doesn't attempt to create the database if it already exists.
N/A: Mantis does the right thing.
As a bonus answer, it's apparently not possible to create a lower-privileged user in a Heroku-provisioned PostgreSQL database -- you're stuck with the one user they give you. Which kinda sucks.
Changing the password is easily done through the console. Is there any way to change the master username after creation on RDS for PostgreSQL? If so, how?
You can't change username. You can check the following links that describe how to change master password and if Amazon adds the ability to change username you will find there:
Try to find at AWS CLI for RDS:
modify-db-instance --db-instance-identifier <value> --master-user-password (string)
--master-user-password (string)
The new password for the DB instance master user. Can be any printable
ASCII character except "/", """, or "#".
Changing this parameter does not result in an outage and the change is
asynchronously applied as soon as possible. Between the time of the
request and the completion of the request, the MasterUserPassword
element exists in the PendingModifiedValues element of the operation
response. Default: Uses existing setting
Constraints: Must be 8 to 41 alphanumeric characters (MySQL, MariaDB,
and Amazon Aurora), 8 to 30 alphanumeric characters (Oracle), or 8 to
128 alphanumeric characters (SQL Server).
The Amazon RDS Command Line Interface (CLI) has been deprecated. Instead, use the AWS CLI for RDS.
Via the AWS Management Console, choose the instance you need to reset the password for, click ‘Modify’ then choose a new master password.
If
you don’t want to use the AWS Console, you can use the
rds-modify-db-instance command (as per Amazon’s documentation for RDS)
to reset it directly, given the AWS command line tools:
rds-modify-db-instance instance-name --master-user-password
examplepassword
No. As of April 2019 one cannot reset the 'master username'.
You cannot do it directly. However you can use the database migration service from AWS:
https://aws.amazon.com/dms/
Essentially you define the current database instance as your source and the new database with the correct username as your target of the migration.
This way you migrate the data from one to another database instance. As such you can change all properties including the username.
This approach has some drawbacks:
You need to configure the migration. Which takes a bit of time.
The data is migrated. This may lead unexpected behavior since not everything is eventually migrated (e.g. views etc.)
It depends how you setup everything you may experience a downtime.
Though this may not be ideal for every use-case, I did find a workaround that allows for changing the username of the master user of an AWS RDS DB.
I am using PgAdmin4 with PostgreSQL 14 at the time of writing this answer.
Login with the master user you want to change the name of
Create a new user with the following privileges and membership
Privileges and Membership
Can login - yes
Superuser - no (not possible with a managed AWS RDS DB instance, if you need complete superuser access DO NOT use a managed AWS RDS DB)
Create roles - yes
Create databases - yes
Inherit rights from the parent roles - yes
Can initiate streaming replication and backups - no (again, not possible directly without superuser permission)
Be sure to note the password used, as you will need to access this new account at least 1 time to complete the name change
Register a server with the credentials created in step 2. Disconnect from the server but do NOT remove it! Connect to the new server created
Expand Login/Group Roles and click on the master user whom you are changing the name
Click the edit icon, edit the name, and save.
Right click the server with the master username, select Properties
Update the name under the General tab if desired
Update the username under the Connection tab to whatever you changed the master username above
Save and reconnect to the server with the master user
You have successfully updated the master user's name on a managed AWS RDS DB instance, proud of you!
As #tdubs's answer states, it is possible to change the master username for a Postgres DB instance in AWS RDS. Whether it is advisable – probably not.
Here are the SQL commands you need to issue:
Create a temporary user with the CREATEROLE privilege (while being logged in with the old master user)
CREATE ROLE temp_master PASSWORD '<temporary password>' LOGIN CREATEROLE;
Now connect to the database with the temp_master user
ALTER ROLE "<old_master_username>" RENAME TO "<new_master_username>";
-- NOTICE: MD5 password cleared because of role rename
ALTER ROLE "<new_master_username>" PASSWORD '<new password>';
Now connect to the database with the <new_master_username> user in order to clean up the temporary role
DROP ROLE temp_master;
And you're done!
Warning
AWS RDS does not know that the master username has been changed, so it will keep displaying the old one and assumes that is still the master username.
This means that if you use the AWS CLI or website to update the master password, it will have no effect.
And when connecting to the database with psql you'll see:
WARNING: role "<old_master_username>" does not exist
While running the server, I am unable to view the layers in GeoServer. I checked the Enabled checkbox, and still I am unable to view the map.
If I login once again into GeoServer, the Enabled checkbox is unchecked.
The below error which I got in logs after starting the Apache Tomcat Server:
Caused by: java.lang.RuntimeException: Unable to obtain connection: Cannot create PoolableConnectionFactory (FATAL: password authentication failed for user "postgres")
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (FATAL: password authentication failed for user "postgres")
Caused by: org.postgresql.util.PSQLException: FATAL: password authentication failed for user "postgres"
ERROR [geotools.jdbc] - There's code using JDBC based datastore and not disposing them. This may lead to temporary loss of database connections. Please make sure all data access code calls DataStore.dispose() before freeing all references to it.
The one thing that can cause this suddenly is password expiration in PostgreSQL, though this is not typical. Most likely the password changed on one of the sides, so check that first.
PostgreSQL allows you to specify that a password expires at a specific timestamp. So you can:
ALTER USER foo WITH PASSWORD 'bar' VALID UNTIL 'tomorrow';
And foo will be able to log in with the password 'bar' until the next day at system time....
So if you can verify that the password did not change on both sides, try this:
ALTER USER foo WITH VALID UNTIL 'infinity';
Of course substitute your real user for foo. This will clear any expiration, or rather move the expiration time indefinitely into the future.
I think this is likely to be that the postgres user is configured to only accept logins from the local machine. You will need to configure it to accept logins from the machine name or ip address you are logining in from or even better create a new user that has only the required permissions to login rather than using the deffault admin postgres user. Even if you are on the same machine using eclipse may be making it look as though you are coming from a different machine depending on your configuration.
Please see here and here about configuring this type of access
Can I connect to a Heroku Postgres database via an web/application without the risk of dropping a table?
I'm building a Heroku application for a third party which uses Heroku Postgres for the backend. The third party are very security sensitive so I'm looking at applying "Layered security" throughout the application. So for example checking for SQL injection attacks at the web/application layer. Applying a "Layered security" approach I should also secure the database in case a potential SQL injection attack is missed, which might drop a database table.
In other systems I have built there would be a minimum of two users in the database. Firstly the database administrator who creates/drops tables, index, triggers, etc and the application user who would run with less privileges than the database administrator who could only insert and update records for example.
Within the Heroku Postgres setup there doesn't appear to be a way to create another user with less privileges (without the “drop table” option). So the application must connect with the default Heroku Postgres user and therefore the risk of a “drop table” might exist.
I'm running the Heroku Postgres Crane add-on.
Has anyone come up against this or got any creative work arounds for this scenario?
With Heroku Postgres you do only have a single account to connect with. One option that does exist for this type of functionality is to create a follower on Heroku Postgres. A follower is asynchronously kept up to date (usually only a second or so behind) and is read only. This would allow you to grant access to the follower to those that need it while not providing them with the details for the leader db.