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.
Related
Let me preface this with the fact that I don't know much about VBA. I have created a database that will be split and the front end will be distributed to 14 different project managers. The database is intended to allow users to enter bi-weekly updates to their projects. I hope to get some guidance on creating usernames and passwords so that PMs can only access their project data.
I don't mind creating and issuing usernames and passwords to each user, but I am trying to avoid creating 14 copies of the database. That would make providing updated databases a nightmare.
Hopefully this isn't too basic of a question for this group.
yes, you can control users access, you need to create a user table in your backend database that will hold their firstname, surname, password, and any other user specific data that you might need, e.g. department, access level, etc.
In your front end, you need a login form and you make that the Display Form for your fe (set in the access options menu). You check the username and password entered matches what is held in your database, and if it's correct, you load the appropriate form, usually a main menu, and show them the appropriate data based on the login they used. You may need to hold the login they used in a TempVar, so you can access it from any form, report, query etc in your frontend.
You will need something like LASsie (Light Application Security) or program a similar solution yourself.
Also, you may enjoy my article Deploy and update a Microsoft Access application with one click.
(If you don't have an account, browse for the link: Read the full article.)
I need to grant access to Big Query to 30 Phd Students in a University on Google Cloud Platform.
Can I give them standalone access to each of them? i.e. One student cannot see other's work unless it is granted.
Creating projects = number of students is not too cost effective.
so can I give 30 access controls to a single project ?
The students need to have full access to Big query (Create, edit, join, download, run) to their respective databases.
The document is indeed confusing. Don't grant any project-level permissions. Just as Katie Sinatra said, go to the dataset Web UI, in the arrow drop's "Share dataset", add email and grant "Can edit". At the time of this writing, after you do the above, the user won't be able to see the dataset in the Web UI, but s/he can still do query in the Web UI just fine if s/he specifies the table correctly, i.e. `project.dataset.table`. (i tested it.) The user can also manually add the dataset to be displayed in the web UI. Here is how to do it, https://cloud.google.com/bigquery/bigquery-web-ui#displayprojects.
What i am still confusing is: after you do the above, when the user do a query, who is paying. My guess is the user is paying. If you want the dataset's original owner (the project under which the dataset is created) to be billed, then my guess is that you need to grant project-level BigQuery Job User permission to the user/email in addition to the above. Then, the user will be able to select the project in the GCP console and hit "BigQuery" to go to the big query Web UI, and be billed under the project. (by the way, if you do this, the dataset can be seen by the user in the Web UI.)
As JL-HN said, it is documented but it is a bit confusing. To give access to an specific dataset, you only need to go the dataset, in the arrow drop it down and click on "Share dataset". Then you only need to add the email of the student that will handle that dataset.
It is great that multiple concurrent users can make changes to an Access database at the same time.
Is Aceess itself keeping track of who made what changes, when?
i.e. if one user is logged in with User Authentication as user "Bob", and another user is "Fred", will there be a way to find out if it was Bob or Fred that made a certain change to the database?
Does each change to the Access database get a timestamp of when it occured?
Short answer is no. Access does not keep an audit of who changed what or when. It also lacks any system (like triggers) that would enable you to keep these logs reliably. Instead, the best you can do is code your application to write necessary audit information to a seperate table but users will be able to bypass it with a little know how. You'll also need to correctly setup access / jet security to prevent users from being able to modify the audit table.
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
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.