Basic PostgreSQL Questions - Do I need another user? - sql

I installed postgreSQL by default with apt-get and I believe it has automatically added a user for me called "postgres".
I only have one database that I want to sort on postgres, so is
there any point creating another user account for this database or
should I just keep with the one which is installed with postgreSQL
"postgres"?
The user account postgres which is made for me, is it given some
kind of default password? Is it recommended that I put in my own
password?

EDIT: I misinterpreted the question, the OP is asking about internal users, not system users
Original Answer: System users for running servers
Most services running on a linux box are given their own independent user, as a standard security practice. In the off-chance that the postgreSQL server was compromised -- either you made a mistake, or there was a vulnerability in postgresql, or whatever -- the attacker can only gain access to the resources allowed to the user running the postgresql server. If that user is root, you lose the machine. If that user is your user, you lose not quite as much. If that user is postgres, which only has minimal access to anything.. you lose the database, and that's all.
So:
You merely need a single user for the postgreSQL server, regardless of what, exactly, that server process is hosting. If (it sounds like one was) a user was created for you automatically, you're all set with this step. If you need to make one manually (sounds like you don't), you would also have to change the permissions so that the new user can access only what it needs to.
That account very possibly cannot be directly logged into; if it has a password at all it's a lot of random data. In order to use the account, you need to start out as root, and then voluntarily "downgrade" yourself to postgres. In the case of the server, root starts the server "under the name of" postgres. I would advise leaving it alone.
Second Answer: Database users
Once you have a server running, the server will keep its own set of users, for the purposes of accessing the database. The simplest architecture you could use there is just having a base user with full permissions do everything. While this works, it is not advised if you are hosting this externally. A more preferable solution is to have a set of users, similar to how the OS is set up: a bunch of users to do specific tasks, and one admin user to rule them all. That said:
You don't have to, but if you are going to host this anywhere (if you're not just using it for personal things, and it's world-accessible), I would advise extra users with limited permissions.
http://archives.postgresql.org/pgsql-admin/2001-10/msg00192.php
There is no password by default; create one with ALTER USER.
Passwords do not take effect unless pg_hba.conf is set up to use them. If
it is, and you have not assigned a password to postgres, you will not be
able to connect as postgres.

re 1)
the default database user that is created during installation is a "superuser" and for the same reason you should not do your daily work as "root", you shouldn't work with a superuser in a DBMS. So the answer is a clear: yes, do create a second user. You can grant that role all privileges on the default database (also called postgres), so that you don't need a second database.
More details on how to create a user and how to grant privileges can be found in the manual:
http://www.postgresql.org/docs/current/static/sql-createuser.html
http://www.postgresql.org/docs/current/static/sql-grant.html
re 2)
I don't know Linux that well, but usually you should have been asked for a password during installation. At some point in the installation a new data directory is initialized using the command initdb which requires a password to run.
If you don't know the password, you log into the postgres linux account, then you can probably run psql without specifying a password. That enables you to reset the database password and create a new user.
More details about users and authentication are in the manual:
http://www.postgresql.org/docs/current/static/client-authentication.html
http://www.postgresql.org/docs/current/static/user-manag.html

Related

tool to give user ability to query database without any ability to alter data

We have a Power User who knows the database very well and has become a great asset since we gave him access with SQL Server Management Studio. Unfortunately, we also gave him a user/pwd used by all Development which carries ability to change data.
Without going into all the wrongs behind having such a privileged db-user and giving such access an end user, is there a tool that would give the user ability to query without any ability to update/insert/drop/ or anything else?
My guess is that the user probably does not want to change the database -- for his/her protection as well as yours.
Just enable this user's login using Window to have read-only access. Or, set up another read-only user and give it to the power user. At the extreme, you may need to change the password of your super user account.
I would recommend in the mean time that you set up a development group, give the group privileges, and assign the developers to the group. They can then login through that id. Perhaps one day, you'll be able to disable your super user account. For now, you should think about ways to work around it.

SQL Windows Authentication Roles?

I have read a lot, but still i can't find the point that i want which is the following:
If i can connect to sql via windows authentication mode, then that mean after i install my software with it's database the user can easily look and manipulate my database, and if i want to revoke any role i will be limiting my program when it's going to access the database.
Is there a way to limit the user access on the database while my program can have a full access without any problems.
The application doesn't have to login to sql using the account that it's being run from. So create a seperate user account for the application that has all the rights it needs and login using that account from the application.
Alternatively, you can just setup a seperate login using sql server authentication and then you won't need another user account.
If this isn't your application and you can't modify it to use a different account to login with, then you could run the application itself under another account. When you hold shift and right click an icon you'll see it gives you an option to do so. However, I don't know how you would set the application up to automatically run that way without the user having to know the password to type in. I think it's possible though.
Also, I think when you set the account up you can set it as a special type that users can't actually login with. So they could know the password to it to run the application, but they wouldn't be able to actually login under that account to do anything with it. This wouldn't prevent someone smart enough from gaining access, but it's a good safeguard.

Problems with createdb in postgres

I have to run a simulation with several postgresql databases spread on different machines which all of them are running linux.
I successfully compiled and built postgresql from the source code and I can also run the server, but when I try to create a new db with this command:
./postgresql/bin/createdb db1
I get this error:
createdb: could not connect to database postgres: FATAL: role "giulio" does not exist
where giulio is my username to access all the machines.
On some machine it works while on other it does not. I really cannot figure out the root of the problem. I suppose it is something related with the access control of postgres.
I did several research on google but I was not able to found and to solve the problem.
Does anyone know how to get this work?
Thanks,
-Giulio
PostgreSQL has its own users and roles that are separate from that of your OS. Generally there is a dedicated super user, postgres. For user management info, look here:
http://www.postgresql.org/docs/9.1/interactive/user-manag.html
When executing postgres commands, you need to specify the user with the -U flag (unless you are already logged in as an existing db user). When you called the createdb script, because you didn't use the -U flag, the server assumed that the uid of the caller (giulo) should be used, but you didn't add a user "giulio" to the db, and hence the error message.
So execute the command as
./postgresql/bin/createdb -U postgres db1
and it should work. Then, later on, you may want to create other users and roles in your db rather than doing everything as the superuser.
I would assume that on the machines where the user "giulio" is already known, you executed initdb with exactly this user making him the DB superuser. A quote from inidb(1) (emphasis mine):
--username=username
Selects the user name of the database superuser. This defaults
to the name of the effective user running initdb. It is really
not important what the superuser's name is, but one might choose
to keep the customary name postgres, even if the operating sys‐
tem user's name is different.
On the other machines I assume you did execute initdb with another user, hopefully using postgres.
In order to get back on the standard track I propose, that you delete the database cluster on the machines where "giulio" is the superuser and setup a new database cluster using the standard postgres user. Then add another user "giulio". This will avoid more confusion down the road as some scripts/programs expect a superuser account named postgres.
My answer was more simple...I realized I needed to just run the following:
brew install postgresql
then to check if it worked I ran:
which createdb
to check the file path and if it worked, and it had ! Hope this helps.

SQL Server 2005 (Express) - Login vs User

I'm quite new to Microsoft SQL Server. I have some experience with MySQL, and there you have a user with privileges, if I understand things right; these privileges decide which databases you have access to on the MySQL server.
However now I am in the situation where I have to restore a database on my SQL Server 2005 Express, and this database has it's own users and user password. So if I want to make these users accessible from the outside (so that they can connect to my server), how would I go about that?
To illustrate clearer; say there are two login accounts on the database server "Mike" and "John", and on the database "Animals" there are two users; "Chris" and "Jeff".
I need Jeff to be able to sign in to get access to the database. Is there a good way to make this happen without creating new users/logins? And if not, what is the best/most common solution?
I would really appreciate any helpful input on this!
One server-level object (login) is mapped to multiple database-level objects (users).
A login cannot be mapped to more than one user within a database, but can be mapped to at most one user in each database.
Therefore, you need to create new logins for those users, but map them to existing users. This is done with ALTER USER command. Or, if you don't have any use for the Mike and John logins apart from mapping them to those existing users, you can do so, too.
Any user needing to access a database needs to either have their own login, or you can create a login for a Windows security group and grant access that way to a whole set of users. Then if you need to give access to more users in the future you can just add them to the windows security group.

How to switch database schema's?

I'm working on a Delphi/WIN32 application that uses an SQL Server database as back-end, using ADO to access the data. There are many users who use this application, but one user is using a special setup: they have multiple database schema's and every schema contains the complete datamodel for the application. Every schema also has a database user which defaults to the specific schema. They also have a separate login account for every database user, allowing them to control which schema to use simply by using a different login account in the connection string.
They use this setup to have a single, centralized database which supports multiple offices. Normally, every office would have it's own database but here, every office has their own schema.
I like this solution that they're using. I haven't thought about this before simply because the application is normally used by single offices. Only this customer had a need to have a centralized database. The application works just fine, even though it's unaware of these schema's, simply because the login account will default to the correct schema.
But now they've asked if it's possible to change the code in a way that the user can select the schema to which they want to connect. Thus, a user needs to be able to switch between schema's in the application. And I don't want to rewrite the code to support these schema's simply because I need to keep the SQL code database neutral. So I'm looking for a way to switch a user to another schema without much impact on the code itself.
Any suggestions?
How about changing the default schema of the user?
ALTER USER <user name>
WITH DEFAULT_SCHEMA = <desired schema>;
Of course you will need to execute this under escalated privileges as I'm sure you don't have all users with ALTER USER capabilities.