all the dbas access via arcos and login as common oracle user in putty session and log into database as sys as sysdba.
scenario, user A logs into a putty session as common oracle user via ARCOS, then logs into the database as sys as sysdba.
My question is can I set audit for sys user if they are manipulating a table, can i get information that user 'A' connected through putty as oracle user into the database and executed some query?
Yes, SYS operations can be audited. Depending on whether you are using tradition or unified auditing in your database, check the following documentation links:
Traditional Auditing: https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/AUDIT_SYS_OPERATIONS.html#GUID-58176267-238C-40B5-B1F2-BB8BB9518950
Unified Auditing: https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/configuring-audit-policies.html#GUID-D352B575-2EA9-451D-9170-FD9298993DEF
Related
I need to create users in Firebird 3.0 embedded databases, but using with standard command returns error.
command:
CREATE USER miusuario
PASSWORD 'miclave';
return:
Engine Error (code = 335544382): Missing user management plugin.
SQL Error (code = -901): Unsuccessful execution caused by system error that does not preclude
successful execution of subsequent statements
I need to create the users on both in runtime and in development.
Any idea how to solve this problem? I've looked in the Firebird documentation and can't get anything to help me.
I do not use the Firebird in server mode, only embedded.
Firebird Embedded does not perform authentication1, and it will accept any username you specify at connect. Creating users is unnecessary, and in your case impossible because it looks like the user management plugin is not configured or available (setting UserManager in firebird.conf). However, even if that plugin was configured, it would be pointless to create users if you only use Firebird Embedded, because Firebird Embedded won't actually use the data of that user.
In Firebird, privileges are granted to usernames not to user records in a security database2. So, even though there exists no user with that username, you can grant it rights (in fact, that is also possible in Firebird server).
You can login (password is ignored) with any username when using Firebird Embedded. The logged in user will then assume any rights granted to that username.
1: This has always been the case on Windows, on Linux this is only the case since Firebird 3, in earlier versions on Linux, Firebird Embedded did perform actual authentication using the security database
2: Except for a small set of privileges like admin in security database and database creation privileges
I am trying to connect to DB2 database to import source structure. I tried using ODBC DB2 Wire Protocol Driver Setup. I provided IP Address, TCP Port, Location ( DB2 to Z/OS and Iseries), but when I click on test connection I get below error:
[Informatica][ODBC DB2 Wire Protocol driver][DB2]NULLID.DDOS510A DOES NOT HAVE PRIVILEGE TO PERFORM OPERATION PACKAGE ON THIS OBJECT.
Same method I tried in lower environment of DB2 and connection works. but in higher environment I get this error. ( I verified login in the database directly and my user id has login access).
This is not a programming question, it is about configuration.
The reason that it works on one database, but fails on another, is because only one of the databases has the correct permissions.
Ask the DBA to grant relevant privileges to the userid at the database.
You will find more details at the following IBM technote and also at here.
I have a firebird database in a .fdb file, but the database do not have the SYSDBA user and I don't remember the credentials to login into the database. Are there any way that could reset the database credentials?
Like said by Mark, it is not that the database "does not have SYSDBA user" - databases in Firebird 2.x never have users - but that old trick was used to create SYSDBA named role in order to trigger names collision on login.
After scanning through 2007 Security presentation I have two suggestions for you.
You can try some tool that opens Firebird databases without using Firebird itself to learn what username can pull you out of the deadlock.
One such tool is Database Explorer in the IBExpert. Full IBExpert is paid for non-USSR states and free IBExpert Personal probably does not have the tool. But I hope the tool works in IBExpert Trial. Another tool is IBSurgeon FirstAID. And probably there are more tools featuring data extraction from corrupt databases. You only need to find and read one specific row.
The query to create the blocking role is given on the 23rd page of the presentation.
INSERT INTO RDB$ROLES(RDB$ROLE_NAME, RDB$OWNER_NAME)
VALUES (‘SYSDBA’, ‘LOCKSMITH’);
So you would have to look into the said table, find the row with the said role, and learn the username that has authority over that role (in the example it was LOCKSMITH).
After that you connect to any other database on the same server and you create the user with the name you learnt. Then you use that name to login into the problematic database and to DROP ROLE SYSDBA; COMMIT;.
You also can use Firebird Embedded. All server-coded security checks are bypassed in the Embedded edition of FB 2.x (but if DB designer added some ad hoc security checks in triggers - they will work). So you login into the problematic database using Firebird Embedded edition, any username and any password, and after that you drop the access blocking role.
In Firebird database doesn't contain password (until v3.0 as mentioned by #Arioch'The). The password is used only for server. Another words, you can copy database file from existed server to another (with known password) and open the database file.
I created a Firebird database by an account other than sysdba. If I put a copy of this db to another machine, I can open it by sysdba account and the 'masterkey' password. Thus this is real risk if some one can take a copy of it.
Is there some way to prevent this scenario?
The user that created a database is "just" the owner of the database, the sysdba user is administrator and is allowed to do anything to all databases on a Firebird server. This is a very good reason to never use masterkey as your password on a production server.
The usernames and passwords in Firebird 2.5 and earlier are stored in a security database (security2.fdb) that is part of the Firebird installation. So moving a database to another server (or replacing the security2.fdb) will allow "unauthorized" persons to access the database. Note that I put unauthorized in quotes here, because if a person has direct file access so they are able to make a copy of the database, or replace the security2.fdb, they have sufficient authorization on your server to do anything they want (or the security of your system has been breached).
In Firebird 3, it will be possible to store users in the database itself, but this still requires server-side configuration, so - as far as I know - this will not restrict much in this scenario. Firebird 3 will also provide support for database encryption which could allow you to only give access on a specific server, or with users that provide a specific key. Unfortunately Firebird 3 only provides the API, but not the encryption. That is left to users or library providers to implement.
There is also a trick to create a role with the name SYSDBA in your database which will prevent a user with username sysdba to connect to the database. But this is easy to circumvent by using a hex editor and some knowledge of the internal structure of a Firebird database to undo this. If the person really wants access to your data, they can also just compile a Firebird server that skips or ignores authentication.
All in all, this means that if someone has direct access to the database file, then they can create a copy and open it on another Firebird install one way or another. So the only real way to protect a database file is to make sure that users can only access the database through the Firebird server, don't have direct access to the database files and - except admins - are not able to create a backup of the database.
Even if users only have access through the server, they can still make a logical copy of the entire database structure, and all data they are allowed to access.
Consider reading Firebird File and Metadata Security
On a server I have two databases ( say db1 and db2 ). I have a superuser called user1.
My requirement is to disable user1(super user) for database db1.
So that using user1 I can only connect to db2 and not to db1.
How can this be done.
Note : postgres version is 8.0 and both the databases are on same database cluster.
Remove their superuser rights entirely. Make them the owner of db2 (ALTER DATABASE db2 OWNER TO whatever_user), so they can do anything to db2 except limited superuser-only operations like loading C extensions.
You cannot restrict superusers. That's the point. Superuser-only operations are ones that break through the usual access control rules. For example, loading a user-defined C function allows you to write and load a function that opens pg_hba.conf and rewrites it, or just manipulates the system catalogs directly. Similarly, the adminpack functions let you do direct file system access, so they're superuser-only.
If they're a superuser, they can just read pg_hba.conf, see that your user ID has the right to log in to db1, then change your password then log in as you.
Asking to limit a superuser to one DB is like asking if you can make a user root, but only for one subdirectory. (OK, so with SELinux you can kind-of do that, but it's complicated).
If you truly must do this, the only way to do it is to split db1 and db2 into different PostgreSQL servers running under different unpriveleged system user IDs. Each has its own separate shared_buffers, data directory, listening (ip-address, port) combo, WAL, user IDs, database lists, etc. Since they're running under different system users they don't have the right to read or write each others' data directories, so they are isolated. They must listen on different ports and/or different IP addresses, though you can use PgBouncer to make them appear to be the same server to external clients.