Does anyone know how to add new user on rocket universe? - jdbc

I have installed Rocket Universe database on my computer, however, I need a username and password to connect through JDBC. Do you know how I can add a new user?
Thank you

You local user account should get you access as long as it has access to the Universe database directory. Universe uses the OS's access control to restrict/allow access to the database. Therefore, any new user added to your OS will also be a database user if their account has access to the Universe database directory.

Related

phpmyadmin: is there any point using dbconfig-common in installation?

The default Ubuntu phpMyAdmin install asks whether dbconfig-common should be used. If you answer Yes, then:
the install creates a new (MySQL) user named phpmyadmin with the password you supply
this user is given rights only to the phpmyadmin database (with only usage on everything else)
the new user's username and password are stored in /etc/dbconfig-common/phpmyadmin.conf, with the passsword in clear
phpMyAdmin is actually installed with auth_type=cookie, so it doesn't need any new users. You can log in as any existing MySQL user.
I'm having trouble understanding what the point of dbconfig-common actually is. User phpmyadmin doesn't appear to be needed, and only has rights on a database that isn't important to the end-user, and creating a new user increases the attack surface. If I drop the phpmyadmin user from MySQL, it doesn't seem to affect phpmyadmin functionality at all, except that I get a warning (access denied for user 'phpmyadmin'#'localhost').
Is dbconfig-common doing something else that's important, or should I try to set up the phpmyadmin config file manually? The current docs appear to be here, but they don't answer the question.

Accessing unencrypted H2 database without credential knowledge

We are cleaning up servers for a customer and have stumbled upon an old application using an H2 database. While the accessing applications have credentials in their configuration files, none of them seem to work.
Even the "sa" user access is not known. As far as I can see, the password for "sa" defaults to an empty string, but access with "sa"/"" is denied (Wrong user name or password [28000-182] 28000/28000 (Help)).
As said, the database is not encrypted. Looking at the file, I can see the SQL statements for the tables, even some table contents.
Is there any way to gain access to that database? As far as my searches have shown it's only possible using the "sa" user. I'm looking for something along the lines of "--skip-grant-tables" from MySQL.
The easiest solution is probably:
Try to login to the database without password. This will fail (wrong user name or password), but it will run transaction log recovery so that the database is in a consistent state.
Then, use the Recover tool (org.h2.tools.Recover) to generate a SQL script.
Edit the script: Change the password for the default user.
Run the script. That way you get a new database.

IBM DB2 "Administrator" does not have the privilege to perform "Select"

I've been testing a software I helped develop, which resides on a 32-bit application server. It is to connect to a 64-bit database server, which uses IBM DB2 v10.1.
I was the one to setup the DB2, but I'm pretty sure it has since been modified; I am no longer able to connect using the Username/Password: db2admin/db2admin.
Instead, I have to use Administrator/p#ssw0rd. I do not recall creating that user myself - it is a local account on the computer itself - but from my ODBC tests, it can connect to the database.
However, it appears it doesn't have any privileges. My attempts to see where this 'user' is using Data Studio 3.2.0 have failed, though given my experience (lack thereof) with DB2, this is not surprising.
My concerns are two-fold:
To find where this 'Administrator' resides.
And to modify its privileges to replicate that of db2admin, which, iirc, is a Database Administrator.
My attempts to research the problem on the net was met with failure - either the so called solution doesn't work, or it is too complex for me to understand if it did work (it didn't).
I have tried the following:
Modifying the Database directly via Data Studio 3.2.0; Right clicking on the database, selecting Manage Privileges, and checking everything I could find - note that I did not find any 'Administrator', just a 'PUBLIC', 'DB2ADMIN', 'SYSDEBUG'. Also, it doesn't seem to save.
'Select * from SYSCAT.DBAUTH where GRANTEE = 'Administrator'; This produces a long list of tables, I guess. Don't know what to do with them, but if I replace 'Administrator' with 'db2admin', I get exactly the same result.
Creating a new user called 'Administrator' using Data Studio;
Please, I'd like some light shed on this; DB2 is an extremely frustrating database. I'm using DB2 v10.1, Data Studio 3.2.0, and Windows Server 2008.
DB2 authentication relies on an external mechanism, such as OS security or ldap. If your case, it seems it is Windows security.
DB2 authorisation is internal, so any grant is inside the database, with some exceptions.
There are several authorities in DB2, some at instance level and other at database level. Those at database level, you can find them inside the database, by querying the catalog, and they can be assigned to a user or to a group.
The other authorities, at instance level, are associated to a OS group (external mechanism)
The highest authority in a database is DBADM, and the highest authority at an instance level is SYSADM. Every user in the associated group to SYSAMD becomes automatically DBADM in all database inside the instance.
Well, this is just a short explanation of how DB2 security is. It means that you 'Administrator' user has the 'connect' privilege (sometime 'connect' privilege is public, it means, any user can connect), but it does not have any other privilege, nor authority.
Finally, in Windows environment, there is another security layer, that associates users in two groups DB2ADMNS and DB2USERS. For more information check this link http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.sec.doc/doc/c0023391.html
Well, I solved it, but it remains to be seen why this occurred in the first place;
After creating the user 'Administrator', I modified the privilege by checking everything. It seemed to work.
you have to GRANT a SELECT on the TABLE to the USER.
GRANT SELECT, INSERT ON mytable TO USER peter
"db2 is not frustrating!"

How to create a user in Oracle SQL developer

I am newbie to oracle sql developer 3.1.07.42, and have just installed it on my machine. I want to make a new connection, but it requires a user and a password which I do not know. I have been googling about it since many days, and have learned that there are some commands to create user, but I do not know where should I run those commands, because I cannot run queries/commands until the connection is created.
Would anyone let me know what should I do?
Steps for creating new user :
1)Open Sql Developer, make new connection.
2)Login with System username and password(made during installation).
3)Once you connect, expand the System user (under Connections, in the left pane) and scroll down to Other users. Then right click users and add new user.
4)Give its username and password & select appropriate system privilege.
5)You are done now, check by making new connection.
Use this below simple commands to create an user
-- Create a user
CREATE USER youruser IDENTIFIED BY yourpassword;
--Grant permissions
GRANT CONNECT, RESOURCE, DBA TO demo;
you should install database software in your local pc/laptop then create user in the database and you can connect the database via sql developer by key in username and password that already created.If you want to connect to other database same step like the previous step but before that you need to point to the remote database.
I thinks you should use "Database Configuration Assistant" to create new database and U can set user name and password and use it in oracle SQL Developer!!!

Allowing oracle db login only to specific application?

We want to allow DB access (Oracle) to our users only through our own application - let's call it "ourTool.exe", installed locally on the users computers. Currently, the users must provide username/password whenever they start "ourTool". The provided password password gets decrypted and we use username/decrypted-password to finally log in to the Oracle DB. This approach prevents the users from directly accessing our DB using third party tools (SQLplus, Excel, Access, ...) and everything in the DB is guaranteed to have been entered/edited using "ourTool".
Now, one of our clients wants to allow its users "single sign-on" (with SmartCards/Oracle PKI). With this, the user will be able connect to our DB without providing any password every time they start "ourTool". But the same will be true for the potentially dangerous tools like SQLplus, Excel, Access, etc.
Is there a way to prevent this? How can we make sure that every record in our DB is only created/edited/deleted using "ourTool" in this scenario?
Since it's your application and you have control of the source, you can use either password protected database roles or Secure Application Roles that are enabled from ourTool.exe. (see http://www.oracle.com/technology/obe/obe10gdb/security/approles/approles.htm ).
For example, with a password-protected database role, the initial connection would be with only the CREATE SESSION privilege, and then ourTool.exe would issue the SET ROLE with password known only to you. Any other application doesn't have the information to set the role. Obviously, the privileges are granted only to the role and not directly to the user in this configuration.
By default, OCI transmits the calling application EXE name and you can access it by querying v$session:
SELECT program
FROM V$SESSION
, which you can do in an AFTER LOGON trigger.
But this can be easily overriden and should not be relied upon.
I renamed my sqlplus.exe to myTool.exe and after making a connection with myTool.exe
SELECT program
FROM V$SESSION
where username = 'SYSTEM';
Returns:
myTool.exe
So be aware, as Quassnoi said: although usable in some circumstances it's certainly not bullit proof.

Resources