I am new to Oracle databases(I am using Oracle Database 11g Express Edition) and sqldeveloper. I have this doubt
When creating a new connection in sqldeveloper what is actually happening?
Creating a new database or connecting to an existing databasE?
If I create multiple connections are they pointing to a single database or different databases, if the later then how to choose a database name while creating a connection
You are establishing a connection to user (i.e. schema) which resides in an (Oracle) database. One database contains many users, so - create one connection per user.
Creating a connection does NOT create a new database; it is done differently. I don't think that 11gXE offers that option; you'd need a Standard or Enterprise Edition.
No problem if you use multiple databases (most of us do). I prefer keeping them in TNSNAMES.ORA file, in a directory used by the TNS_ADMIN environment variable. Currently, there are 94 databases I have access to, each of them having many users.
In your case, 11gXE is (probably) installed on your own computer, and you'll use one of its users (HR?), so - just connect to it. If it is locked, you'll have to unlock it first, though - in that case, create connection to SYS (don't forget to connect AS SYSDBA), then
ALTER USER hr ACCOUNT UNLOCK;
ALTER USER hr IDENTIFIED BY hr;
and then create connection to "hr" whose password is now set to "hr" (all lower case).
Related
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.
DreamFactory installer (via php artisan) is prompting "Enter your database name:", not sure what database means, it wants me to set a brand new database name or a name for existing one?
You need to provide a database for DreamFactory to use to store its configuration options and users. This can be sqlite, mysql, postgres, or sql server (paid option.)
When you run the setup command you need to provide the database connection information for an existing database. If you don't have a database, you can choose the sqlite option instead of one of the others. sqlite is file based and requires no server infrastructure. The database will be created for you automatically in that case.
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
Assume there is an application in a non-stop loop trying to read from database.
I have tried the following but it does not work:
db2 CONNECT TO SAMPLE
db2 QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS
db2 TERMINATE
db2 DEACTIVATE DB SAMPLE
db2 BACKUP DATABASE SAMPLE
It seems as if (DEACTIVATE DB) does not do anything since an application in a loop can still read from the database.
I keep getting the error "The database is currently in use" when trying to backup.
You have to make sure there are not applications connected to the database (db2 list applications). Also, you have to make sure the database is not active (db2 list active databases).
Remember that a quiesce or a force applications, is a asynchronous task. It means that you execute any of them, but when the control is returned it does not mean the applications have bee disconnected.
A typical case is a rollback of a batch process, when the rollback takes several minutes.
QUIESCE DATABASE will not prevent new connections from coming in. I believe you have at least two choices:
Use QUIESCE INSTANCE <instance> USER <username> RESTRICTED ACCESS IMMEDIATE FORCE CONNECTIONS. This will force all existing connections and restricts access for new connections. Only the user specified in USER will be able to connect. Presumably, this will be your administrative account.
If this is a no-go, or if you are unable prevent USER from spawning new connections, you may want to (temporarily) UNCATALOG DB and/or disable the DB2COMM registry variable in order to prevent new connections.
HTH.
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.