As I read, there are certain access privileges given to a user or role in Informix. If I give any of the database level privilege, it will have access to all users/ schemas under that database.
My doubt was that can I restrict this privilege to specific users/ schemas in that database? Do we have any user/schema level privilege in Informix?
If you grant a user CONNECT privilege to a database, then they can access tables within that database for which they have been granted access (which is typically, but not necessarily, all tables in the database). You can also revoke PUBLIC privileges on a table, and then grant access only to named users or roles, and then only those users who have been granted access can access it. Here, "access" means "if they try to SELECT, they need to have been granted SELECT access; if they try to INSERT, they need to have been granted INSERT access; etc.".
By default, when you create a table in an ordinary database, then all users are given select, insert, update, delete privileges on the table. This is done via the equivalent of GRANT ALL ON the_table TO PUBLIC. Note that every user has the permissions granted to PUBLIC, and possibly some extra privileges. Therefore, to ensure only selected users or roles have access, it is necessary to use REVOKE ALL ON the_table FROM PUBLIC. There is an environment variable NODEFDAC=1 and a $ONCONFIG file setting with the same name that suppresses the default 'discretionary access controls' (DAC) granted to PUBLIC. Note that in a MODE ANSI database, no permissions are granted to anyone else by default.
The constraints on users granted RESOURCE privilege in a database are similar users granted CONNECT privilege — the difference is that RESOURCE users can create their own tables, whereas CONNECT users cannot.
If a user is granted DBA privilege, they can access any tables in the database. Be cautious about granting DBA privilege, therefore.
Related
I was given access to a database (turtwig) in Neo4j created by a colleage, who gave me the default role 'PUBLIC' and a custom one called 'modeller'. I am triying to create a new node label but I get this message:
Node label error
When I try to give myself the privilage to create node labels, an error occurs:GRANT ERROR. This same error occurs when I try to grant myself the privileges of assigning privileges with GRANT ASSIGN PRIVILEGE ON DBMS TO modeller
Run this command and you will see the privileges that user modeller has.
SHOW USER PRIVILEGES
Granting yourself (as modeller) access for that privilege should be done by admin. Then you should ask your database admin (or colleague) to grant you access to create new nodes.
GRANT CREATE ON GRAPH turtwig ELEMENTS * TO modeller
How to configure a PSQL v11.4 user that is not the superuser and does not own the database.
This user should have full access to create SQL objects and drop them, even
though they do not own the database, so they can not drop the database.
All sql/database objects exist on the PUBLIC schema.
So far I have tried:
CREATE USER app_user WITH ENCRYPTED PASSWORD 'foo_bar';
ALTER USER app_user NOCREATEDB NOCREATEROLE;
ALTER USER app_user VALID UNTIL 'infinity';
GRANT ALL PRIVILEGES ON DATABASE database TO app_user;
When running Rails migrations I get the following error:
remote: PG::InsufficientPrivilege: ERROR: permission denied for table schema_migrations
Seems like the psql best practices is to have a role with privileges
set, then assign the user to be a member of that role. However because everything
is on the public schema all users/roles should have full access right? However
this line in the docs is throwing me off:
"The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege; it is inherent in the owner, and cannot be granted or revoked. (However, a similar effect can be obtained by granting or revoking membership in the role that owns the object; see below.) The owner implicitly has all grant options for the object, too."
from: https://www.postgresql.org/docs/11/sql-grant.html
Also though because the database is being restored via the sudo user, objects
will be owned by the sudo user, however new objects could belong to the
app_user, is this an issue?
You need the CREATE privilege on the database, and you need to pg_dump (or pg_restore with the -x and -O options, so that the restoring user becomes the object owner and no additional privileges are granted.
Some things, like certain extensions, event triggers or functions in untrusted languages (to name a few examples) require superuser rights to create them. Either avoid such objects or create them ahead of time and ignore the errors.
Currently migrating to snowflake from another relational database. Below are the SQL commands that we used in attempt to grant the right permissions. When attempting to create the stored procedure in the DEVELOPER_ARCHIVE database and LANDING_ZONE schema using the DEVELOPER_ROLE, we get an error that we don't have the permissions.
CREATE ROLE IF NOT EXISTS DEVELOPER_ROLE;
CREATE ROLE IF NOT EXISTS DEVELOPER_CRUD_ROLE;
CREATE ROLE IF NOT EXISTS DEVELOPER_READONLY_ROLE;
GRANT ROLE DEVELOPER_READONLY_ROLE TO role DEVELOPER_CRUD_ROLE;
GRANT USAGE ON DATABASE DEVELOPER_ARCHIVE to DEVEVELOPER_CRUD_ROLE;
The role will also need usage on the LANDING_ZONE schema and an additional create procedure grant. Here is a link to the grants documentation (schemaPrivileges);
https://docs.snowflake.com/en/sql-reference/sql/grant-privilege.html
I'm writing an app where Users can create Networks, Networks can have many Rooms and Rooms can have many Devices. For each Network, I'd like to give Users either Admin access, Guest Access or No Access (Admins can add other users as admins or guests, can change network/room/device names etc, guests can only read network/room/device info). Admins of a network would be able to give other users either Admin access or Guest access to any network they are the an Admin of. How would I achieve this using Parse? Things I've tried:
I looked into using PFRoles. Unfortunately, you can't assign a user to be an "Admin" of a specific object graph ie a specific Network. Instead, the "Admin" role would be global to our entire app and adding a user to that role would give them Admin rights to every network.
I could use ACLs directly instead of Roles. Every time I want to change a users permissions in a network, I could walk the entire Network graph and change the ACL on each object to add/remove the user from its acl. This seems error prone.
I could create 2 roles for each network (such as prefix _Admin with the Networks object ID). But the would create 2 X (the number of Networks in the database) PFRoles.
Any ideas?
I have a cics application and i don't want to develop an login screen, instead i want to restrict the access by fetching the user id and then to verify if they are allowed to run my application. Is this possible? Thank you
There are probably better ways of restricting access to certain transactions within a CICS environment than by grabbing the USER ID and comparing to a list. Most shops have developed standard techniques for restricting access to transactions within CICS. However, if you must find the User Id, try something like this:
EXEC CICS ASSIGN
USERID(WS-USERID)
END-EXEC.
where WS-USERID is a working storage PIC X(8) field.
This is a link to the documentation for CICS ASSIGN.
EDIT
How to check against multiple user ids? You need a list of authorized users to compare the current user id against. If the
user id is in the list, the user is authorized to use the transaction. Typically you have a couple options for managing such a list:
SELECT against a database table containing authorized user ids. Use the current user id as the predicate (eg. WHERE USER_ID = :WS-USERID). If you get a row back, the user is authorized.
SEARCH/SEARCH ALL a WORKING-STORAGE table populated with authorized user ids for a match. If you get a match, the user is authorized.
The WORKING-STORAGE table solution is the least flexible since the program may need to be updated and re-compiled each time a new user is added or removed.
However, as pointed out by myself and cschneid, access security is best handled outside of applicaion programs
using something like RACF or ACF2. Your local systems
administration should be able to help you get this set up.
CICS can talk to an external security manager, such as RACF, CA-ACF2, or CA-Top Secret. Applications are often secured at a transaction level by having the correct rules or profiles in place in the external security manager.
This way, security actions are performed external to the application logic. Access is granted by security personnel and not by an application developer.
To follow on to your comment to NealB's answer regarding multiple users: Your security administrators can add all of the userids in question to a group, and then define access permissions to that group for your transaction.
You really should let your security administration handle transaction access. Good system design puts security management outside of the application.
With CICS TS V4.2 and above with the Security Extensions Feature Pack (integrated in V5.2) you can use SAML assertions coming from distributed applications to provide even more granular access control.