I have multiple users on my Informix 12.10 server. I want to limit certain users delete permission in Informix so that particular users cannot delete any tables in Informix.
Do you mean "delete tables" as in "DROP TABLE", or delete (from) tables?
If you want to limit the ability to drop (non-temporary) tables, then you should know that only users with RESOURCE or DBA privilege can drop tables; only users with DBA privilege can drop tables they don't own. The cure to this problem is to limit the people who have either RESOURCE or DBA privilege.
If you don't want people to delete from specific tables, revoke delete privilege from PUBLIC (because anyone can do what PUBLIC can do) on each of those tables, and also from each user otherwise granted DELETE permission. That tends to get a bit verbose, but is doable with a shell script to generate the DDL:
for table in "$#"
do
echo "REVOKE DELETE ON $table FROM PUBLIC;"
for user in user1 user2 user3 user4
do echo "REVOKE DELETE ON $table FROM $user;"
done
done
Save the output in a .sql file and run it with DB-Access. You can get much fancier with how you generate the list of users. You could also generate a comma-separated list of user names and run a single REVOKE statement. You pays your money and takes your pick. For a given table ('elements' in this example), this SELECT statement lists the users from whom DELETE permission must be revoked:
SELECT a.grantee, t.owner, t.tabname, t.tabid
FROM "informix".SysTabAuth AS a
JOIN "informix".SysTables AS t ON a.tabid = t.tabid
WHERE a.tabauth[5] = 'd'
AND t.tabname = 'elements';
That generates more information than you need — the grantee column is sufficient — but the extra might help you during debugging. Note that if 'user1' grants delete permission to 'user2', and 'user3' tries to run the REVOKE statement REVOKE DELETE ON tablename FROM user2 will not change the permissions. However, a DBA could run REVOKE DELETE ON tablename FROM user2 AS user1. In other words, the grantor matters, as well as the grantee.
You might want to make use of the NODEFDAC environment variable (it's short for 'no default DAC', where DAC is 'discretionary access control') when creating tables to deny PUBLIC default permissions on created tables.
However, that's of limited help and simply setting it does not apply the new rules retroactively.
Related
I am trying to automate creating databases and users in Postgres.
Currently, after I create the databases and users for each database, all users seem to have admin access and can do and see anything, including other databases.
Here is the SQL I'm running:
CREATE DATABASE MY_DB WITH ENCODING 'UTF8';
CREATE USER MY_DB_ADMIN WITH ENCRYPTED PASSWORD 'SUPER_SECRET_PASSWORD';
GRANT ALL PRIVILEGES ON DATABASE MY_DB TO MY_DB_ADMIN;
I'm relatively new to Postgres, so not sure if this is a Postgres nuance thing or SQL in general.
Thanks in advance
Update 1
By "do anything", I mean, I am able to perform selects, create tables etc in other databases.
I have now tried this:
REVOKE ALL ON DATABASE MY_DB FROM MY_DB_ADMIN;
GRANT CREATE, CONNECT, TEMPORARY ON DATABASE MY_DB TO MY_DB_ADMIN;
But this still doesn't work.
User DB_ONE_ADMIN is able to create tables in DB_TWO
GRANT ALL PRIVILEGES ON DATABASE MY_DB TO MY_DB_ADMIN;
The problem is with the last line here, you are granting all privileges on database MY_DB to MY_DB_ADMIN. You need to decide on the access levels for different users if this is something you don't want.
If restriction needs to be applied and current privilege needs to be revoked then use REVOKE command
I created a user and granted him all permissions, i used: GRANT ALL PRIVILEGES TO user1;
but then i tried to select rows from a table that i created with the admin user like this:
select * from sys.table it gives me an error message table or view doesn't exist
then i did: Grant select on table to user1 and it worked.
so does all privileges not include select?
As is often the case, Oracle uses words "approximately".
In this case, ALL doesn't mean "all". From the documentation:
ALL PRIVILEGES
Specify ALL PRIVILEGES to grant all of the system privileges listed in
Table 18-1, except the SELECT ANY DICTIONARY, ALTER DATABASE LINK, and
ALTER PUBLIC DATABASE LINK privileges.
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sqlrf/GRANT.html#GUID-20B4E2C0-A7F8-4BC8-A5E8-BE61BDC41AC3
Notice the "except" part. "All" should mean "all", that is, "no exception"; yet........
Relevant to your question: ALL PRIVILEGES does not include SELECT ANY DICTIONARY. Most likely, whatever table or view you were trying to select from is a dictionary table (or view); which explains why granting ALL PRIVILEGES didn't work, but granting access directly on the table/view did.
If you want to grant access to all dictionary objects, you can grant SELECT ANY DICTIONARY to the user.
After you are done playing with these explicit grants, you may want to consider granting system roles to the users who need them (and only to those users), instead of hunting down all such exceptions.
Background info:
I administrate a database in SSMS. I am the only administrator. I have users creating tables, and then they want to grant select permissions on those tables, to other users. But they are not allowed to do it because they are not administrators or have CONTROL permission on the schema.
Question:
How can I as an SSMS database administrator let users grant SELECT on tables they create to other users, without making them admins or giving them CONTROL permissions?
I would simply get users to create a table in their own schema along the lines of (SSMS syntax may be different, this is just meant to be illustrative):
create table select_access (
table_name varchar[50],
user_name varchar[50],
is_active varchar
)
Then have an admin job run periodically (every five or ten minutes, for example) and, for every applicable user, examine the entries in that table.
If there's an entry for a table not currently having the permission (with is_active set to Y), grant the permission. If there's an entry for a table currently having the permission (with is_active set to N), remove the permission.
That way, they have full control over select permissions on their tables without getting you involved.
To share a table, they just create it, add entries to select_access for each user they want to share it with, then wait for your job to run.
To disable, they just set the is_active field to N for the users they want to revoke access for and, again, wait for your job to run.
The use of is_active is just to make your life easier, as your only necessary source of information is just that table.
You could make it smarter by just letting them delete the row for the given user/table but then you'd have to process the table and all their tables that may have access granted but no longer have an entry in select_access.
Just make sure any table they grant permissions to is a table in their schema, not one of the system tables :-)
I need to run queries as a "user" which is a record in a table, with permissions based on a record value of that user.
I have a database with a tUsers Table, such as:
ID Username Email Role
1 Pieman mail.com Admin
2 Cakedude mail.co.uk Receptionist
3 Muffin gh.com Other
I need to have it so only "users"/records with "Role" of "Admin" can view and edit the table, and "Receptionist" view it etc.
I know of and use GRANT for permissions, but don't know how to run a query as a user based on a table record and to have the permission only GRANTED if that users' role is "Admin"
So if I have:
USE DB1;
GRANT SELECT ON OBJECT::tUsers TO Admins;
GO
SELECT * FROM tUsers
How do I make that run as say tUser with ID 1, and the GRANT if the users' role = "Admin"
I'm sure I've seen this done before.
I'm fairly new and still learning the correct terminology, so if this is a duplicate question, or is essentially just describing an sql Function sorry.
I don't think you can grant or revoke permissions to users in your own user table. However you can of course restrict queries based on your own user table.
One solution is to do it in your application. Verifier permissions before you do anything for him/her.
Another solution is to use stored procedures which take user id as parameter and do the checking for you in a central place.
The third one is to user parameterized views where you filter out entries one user can't access.
There are other solutions but the basic idea is you need somehow check permissions instead asking dBm server to do it for you.
I'm moving from MySQL to PostgreSQL and have hit a wall with user privileges. I am used to assigning a user all privileges to all tables of a database with the following command:
# MySQL
grant all privileges on mydatabase.* to 'myuser'#'localhost' identified by 'mypassword';
It appears to me that the PostgreSQL 9.x solution involves assigning privileges to a "schema", but the effort required of me to figure out exactly what SQL to issue is proving excessive. I know that a few more hours of research will yield an answer, but I think everyone moving from MySQL to PostgreSQL could benefit from having at least one page on the web that provides a simple and complete recipe. This is the only command I have ever needed to issue for users. I'd rather not have to issue a command for every new table.
I don't know what scenarios have to be handled differently in PostgreSQL, so I'll list some of the scenarios that I have typically had to handle in the past. Assume that we only mean to modify privileges to a single database that has already been created.
(1a) Not all of the tables have been created yet, or (1b) the tables have already been created.
(2a) The user has not yet been created, or (2b) the user has already been created.
(3a) Privileges have not yet been assigned to the user, or (3b) privileges were previously assigned to the user.
(4a) The user only needs to insert, update, select, and delete rows, or (4b) the user also needs to be able to create and delete tables.
I have seen answers that grant all privileges to all databases, but that's not what I want here. Please, I am looking for a simple recipe, although I wouldn't mind an explanation as well.
I don't want to grant rights to all users and all databases, as seems to be the conventional shortcut, because that approach compromises all databases when any one user is compromised. I host multiple database clients and assign each client a different login.
It looks like I also need the USAGE privilege to get the increasing values of a serial column, but I have to grant it on some sort of sequence. My problem got more complex.
Basic concept in Postgres
Roles are global objects that can access all databases in a db cluster - given the required privileges.
A cluster holds many databases, which hold many schemas. Schemas (even with the same name) in different DBs are unrelated. Granting privileges for a schema only applies to this particular schema in the current DB (the current DB at the time of granting).
Every database starts with a schema public by default. That's a convention, and many settings start with it. Other than that, the schema public is just a schema like any other.
Coming from MySQL, you may want to start with a single schema public, effectively ignoring the schema layer completely. I am using dozens of schema per database regularly.
Schemas are a bit (but not completely) like directories in the file system.
Once you make use of multiple schemas, be sure to understand search_path setting:
How does the search_path influence identifier resolution and the "current schema"
Default privileges
Per documentation on GRANT:
PostgreSQL grants default privileges on some types of objects to
PUBLIC. No privileges are granted to PUBLIC by default on tables,
columns, schemas or tablespaces. For other types, the default
privileges granted to PUBLIC are as follows: CONNECT and CREATE TEMP TABLE
for databases; EXECUTE privilege for functions; and USAGE privilege for languages.
All of these defaults can be changed with ALTER DEFAULT PRIVILEGES:
Grant all on a specific schema in the db to a group role in PostgreSQL
Group role
Like #Craig commented, it's best to GRANT privileges to a group role and then make a specific user member of that role (GRANT the group role to the user role). This way it is simpler to deal out and revoke bundles of privileges needed for certain tasks.
A group role is just another role without login. Add a login to transform it into a user role. More:
Why did PostgreSQL merge users and groups into roles?
Predefined roles
Update: Postgres 14 or later adds the new predefined roles (formally "default roles") pg_read_all_data and pg_write_all_data to simplify some of the below. See:
Grant access to all tables of a database
Recipe
Say, we have a new database mydb, a group mygrp, and a user myusr ...
While connected to the database in question as superuser (postgres for instance):
REVOKE ALL ON DATABASE mydb FROM public; -- shut out the general public
GRANT CONNECT ON DATABASE mydb TO mygrp; -- since we revoked from public
GRANT USAGE ON SCHEMA public TO mygrp;
To assign "a user all privileges to all tables" like you wrote (I might be more restrictive):
GRANT ALL ON ALL TABLES IN SCHEMA public TO mygrp;
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO mygrp; -- don't forget those
To set default privileges for future objects, run for every role that creates objects in this schema:
ALTER DEFAULT PRIVILEGES FOR ROLE myusr IN SCHEMA public
GRANT ALL ON TABLES TO mygrp;
ALTER DEFAULT PRIVILEGES FOR ROLE myusr IN SCHEMA public
GRANT ALL ON SEQUENCES TO mygrp;
-- more roles?
Now, grant the group to the user:
GRANT mygrp TO myusr;
Related answer:
PostgreSQL - DB user should only be allowed to call functions
Alternative (non-standard) setting
Coming from MySQL, and since you want to keep privileges on databases separated, you might like this non-standard setting db_user_namespace. Per documentation:
This parameter enables per-database user names. It is off by default.
Read the manual carefully. I don't use this setting. It does not void the above.
Maybe you could give me an example that grants a specific user
select/insert/update/delete on all tables -- those existing and not
yet created -- of a specific database?
What you call a database in MySQL more closely resembles a PostgreSQL schema than a PostgreSQL database.
Connect to database "test" as a superuser. Here that's
$ psql -U postgres test
Change the default privileges for the existing user "tester".
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT INSERT, SELECT, UPDATE, DELETE ON TABLES
TO tester;
Changing default privileges has no effect on existing tables. That's by design. For existing tables, use standard GRANT and REVOKE syntax.
You can't assign privileges for a user that doesn't exist.
You can forget about the schema if you only use PUBLIC.
Then you do something like this: (see doc here)
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
I don't want to grant rights to all users and all databases, as seems to be the conventional shortcut, because that approach compromises all databases when any one user is compromised. I host multiple database clients and assign each client a different login.
OK. When you assign tables to the correct role, the privileges granted will be role-specific and not to all users! Then you can decide who to give roles to.
Create a role for each database. A role can hold many users.
Then assign a client-username to the correct role.
Also assign your-username to each role if needed.
(1a) Not all of the tables have been created yet, or (1b) the tables have already been created.
OK. You can create tables later.
When you are ready, assign tables to the correct client role.
CREATE TABLE tablename();
CREATE ROLE rolename;
ALTER TABLE tablename OWNER TO rolename;
(2a) The user has not yet been created, or (2b) the user has already been created.
OK. Create usernames when you are ready. If your client needs more than one username simply create a second client-username.
CREATE USER username1;
CREATE USER username2;
(3a) Privileges have not yet been assigned to the user, or (3b) privileges were previously assigned to the user.
OK. When you are ready to give privileges, create the user and assign the correct role to her.
Use GRANT-TO command to assign roles to users.
GRANT rolename TO username1;
GRANT rolename TO username2;
(4a) The user only needs to insert, update, select, and delete rows, or (4b) the user also needs to be able to create and delete tables.
OK. You run these commands to add permissions to your users.
GRANT SELECT, UPDATE, INSERT, DELETE ON dbname TO role-or-user-name;
ALTER USER username1 CREATEDB;