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.