In a newly created database, I don't get any error message when I log in with the wrong user and password (the users TTT and AAA don't even exist)
[root#fewww bin]# ./isql /opt/db/treewww/ftree.db -user ttt -password bbb;
Database: /opt/db/treewww/ftree.db, User: TTT
SQL> exit;
[root#fewww bin]# ./isql /opt/db/treewww/ftree.db -user aaa -password ccc;
Database: /opt/db/treewww/ftree.db, User: AAA
SQL> SELECT rdb$get_context('SYSTEM', 'ENGINE_VERSION') from rdb$database;
RDB$GET_CONTEXT
===============================================================================
3.0.2
At the same time, I get a 'regular' error message in another database when I use the wrong login credentials:
[root#fewww bin]# ./isql /opt/db/testwww/ftest.db -user aaa -password ddd
Statement failed, SQLSTATE = 08001
I/O error during "lock" operation for file "/opt/db/testwww/ftest.db"
-Database already opened with engine instance, incompatible with current
Use CONNECT or CREATE DATABASE to specify a database
Could you please explain the matter?
You only specify a path to the database, and not a hostname, and as a result, isql uses the Firebird Embedded database engine to open and access the database, and not the Firebird server. Since Firebird 3, Firebird Embedded no longer verifies passwords on Linux (it never did this on Windows, and now Linux follows the same rule), see also the Firebird 3 Release Notes.
This applies the assumption that if a user has direct read and write access to the database file, then they are allowed to open it. The specified username is still used, to apply the privileges granted to that user, and given no passwords are checked, any username is considered valid. Such a user probably won't have sufficient privileges to do much except query system tables, unless you have granted privileges to that username or to the user PUBLIC.
The second error you show likely means that the database was opened by another application using a different Firebird engine (e.g. a Firebird server process in SuperServer mode), or possibly your user and that process don't have the same access rights to lockfiles (not 100% sure about this). You could try connecting through localhost to see if you can access the database that way: isql localhost:/opt/db/testwww/ftest.db -user aaa -password ddd.
Related
I am new to this SQL stuff and I recently installed Postgres 14.3 on my windows machine as part of an online learning requirement. I created a database and a user to connect to the database in the following lines from the shell:
postgres=# create database staff;
postgres=# create user Naruto with encrypted password 'secret';
postgres=# grant all privileges on database staff to Naruto;
postgres=# \c staff Naruto;
password for user Naruto:
After inputting the password I get an error message like this
connection to server at "local host" (127.0.0.1), port 5432 failed: FATAL: password authentication failed for user "Naruto"
Previous connection kept
Whereas the video description from which I am taking tutorials didn't ask for a password prompt but it connected to the database straight up with the designated user.
I have tried numerous suggestions on stack overflow but still, no breakthrough in any way. I'd appreciate any hint because I haven't recorded any progress with my learning recently. Thanks!
The user you created is named "naruto", not "Naruto", because identifiers are case-folded when not inside double quotes. In the \c, however, it is not case folded because at that point is not an identifier, it is more like a command line argument.
Depending on the contents of pg_hba.conf, PostgreSQL might not tell you when you try to login as a nonexistent user. Instead it goes through the motions of authentication, even though authentication is doomed to fail. This is so that an attacker cannot determine which users exist by trying a bunch and looking at the error messages. The real reason for failure is published to the db server's log file, so if you had looked there you should have seen role "Naruto" does not exist.
If you want the user to have a capital letter, put double quotes around the name when you do the CREATE. Alternatively given that you already created the user without the cap, connect to it using the lower-case spelling. And either way, look in the servers log file when you run into problems.
I hope this might help someone in the future. All I had to do was fix the caps for the user I initially created as 'Naruto' and it got executed smoothly.
postgres=# create database staff;
postgres=# create user naruto with encrypted password 'secret';
postgres=# grant all privileges on database staff to naruto;
postgres=# \c staff naruto;
When I try anything in isql, I get the message:
Your user name and password are not defined. Ask your database
administrator to set up a Firebird login.
unable to open database
When I try to create the user I still get the message:
C:\Program Files\Firebird\Firebird_3_0>gsec -user sysdba -password masterkey
use gsec -? to get help
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
unable to open database
But I am the administrator, and I installed it.
How do I create the user SYSDBA in Firebird?
The combination of the "Your user name and password are not defined. Ask your database administrator to set up a Firebird login." with "unable to open database" does not mean the SYSDBA account does not exist, it means that the Firebird process was unable to open the security database to perform authentication.
This can happen if you installed Firebird in C:\Program Files, and you are running the Firebird server as an application (instead of as a service) and UAC is enabled, or you are running as a service, but the user account running the service has insufficient rights to read and write to the security3.fdb file.
You either need to run Firebird as a service (e.g. as configured by the installer), or - if you really want to run Firebird as an application - install Firebird outside of C:\Program Files.
How do I create the user SYSDBA in Firebird?
Connect to any database (security.db or employee) in embedded mode using user name SYSDBA (password is not needed in this mode) and issue SQL command "CREATE USER" as described in Firebird Language Reference.
You can learn more about embedded mode from Firebird 3.0 Release Notes.
I'd like to learn how to use postgres, so I just installed it, set my password, and added the \bin and \lib directories to my system path. I then ran psql in the command line, typed the password that I just set when I was prompted, and now I receive this error:
psql: error: FATAL: password authentication failed for user "me"
I don't understand why that happened. Any ideas? I am using windows 10.
The windows installer asks you to specify the password for the super user named "postgres". But if you just type psql, you are trying to log in as the PostgreSQL which has the same name as your windows OS user. But that PostgreSQL user probably doesn't even exist, much less have the same password as you specified upon installation.
So the first time you log in, you have to tell it to log in as the initial superuser, with -U postgres. Once logged in, you can create a user named 'me' (create it with a password--possibly the same as the first password you assigned, although generally they would be different), and a database named 'me'. From them on, you could log in as this new user to this new database, just by typing psql and then giving the password when it asks.
In general, the initial user and the initial database are only used for maintenance operations. Other tasks should be done with the users and in the databases you set up after the first time you log in. This isn't "the law" of course, it is just "a good idea".
I'm trying to connect to employee.fdb in Firebird3.0 (localhost) using FlameRobin 0.9.3 on a Ubuntu OS.
The connection to Firebird using isql has no issues. I can create users, roles, etc all from the terminal. However, when I attempt to make a connection using FlameRobin I receive a 335544344 "Error while trying to open file Permission denied" response.
This occurs with the SYSDBA profile and any other new user profiles that I create in isql. I can even create new users in FlameRobin but I cannot connect to any database. I've verified in /etc/firebird/3.0/firebird.conf that DatabaseAccess = Full and have attempted to access the db from a couple different folders in case this is a read/write issue. No success.
I feel like I'm missing something obvious. Any thoughts?
Added info in response to Mark (4/26):
The db is stored in /var/lib/firebird/3.0/data/. I have assumed this to be the default location for Firebird DBs and that the server automatically has access to it, but I suppose that might not be the case. Is there a way to confirm server permissions to this directory and/or is this the customary spot to store work?
Terminal Connection with ISQL:
daniel#daniel-desktop:~$ isql-fb
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect '/var/lib/firebird/3.0/data/employee.fdb' user sysdba password 'xxxxxxx';
Database: '/var/lib/firebird/3.0/data/employee.fdb', User: SYSDBA
SQL>
FlameRobin Database Registration Info:
FlameRobin Error:
This is a permissions issue as #MarkRotteveel suggested. Problem was that I installed the server as a user and not as root. Problem solved by removing and reinstalling both Firebird and FlameRobin as root.
I'm getting error "no permission for read/select access to DATABASE" when I try to connect to a Firebird database with a user different than SYSDBA, lets say user SOM.
If I create a new database with SYSDBA on the same server, then grant access to the objects there to SOM, it is connecting without problem, but for this particular database - not. I tried to give all rights, including to the system objects to SOM (I'm using the great IBExpert where this is possible), no success.
c:\Program Files\Firebird\Firebird_2_5\bin>isql -user SOM -password secret
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect "c:\data\data.fdb";
Database: "c:\data\data.fdb", User: SOM
SQL> select * from exampletable ;
Statement failed, SQLSTATE = 28000
no permission for read/select access to DATABASE
Command error: select * from exampletable
I was unable to find way to grant anything to object DATABASE.
What could be the reason is that the problematic database was restored via gbak, version 2.5 from Firebird 3 database (downgrade on this way from Firebird 3 to 2.5).
A possible solution is to restore the database with user SOM, but I don't want that the user SOM is the owner of the database. If I do a backup and restore with SYSDBA, the same problem comes back again.
Solution provided in the firebird-support mailing list:
Attach as SYSDBA and run
UPDATE RDB$DATABASE SET RDB$SECURITY_CLASS = NULL
have you tried gbak from 2.5 to BACKUP FB 3 database?
FB 3 running
place gbak from 2.5 to fb 3 folder, as gbak25. Or, do as you wish, but gbak from 2.5 need to use fbclient.dll from 3.0
gbak25 -b -g -v db.fdb db.fbk -user ... -pass ...
then restore this backup on 2.5.