I am creating a NTService Application which use an Embeded Firebird database. When i configure the service run as Administrator account, It works ok. But when i run service as default Local System Account, I get below error.
no permission for read/select access to TABLE XXXX
Why is that ? I belive there is no system tables or etc in Firebird single sql file. And Windows xp dont have linux like file permissions. Please help.
Regards
J
While the embedded version doesn't authenticate users (doesn't check the username and password against security2.fdb) it still checks the SQL privileges of the user. This means that you still have to grant proper user rights to the username and/or role you're using when accessing the database. It probably worked for the Administrator account because in version 2.1, members of administrative Windows groups were mapped to SYSDBA by default (and thus had all rights on all databases). This changed in version 2.5, you now have to manually configure this (see release notes).
Related
I have a fresh install of a database on AWS. I have installed PG Admin 4 for Web and set up for a user login. This works.
I find it is not possible to connect to the localhost database using 'postgres' as a user, without a password. This appears to be enforced by the dialog. Is there a way around this enforcement? How would a user only having web access ALTER this ROLE? I would expect this to be relaxed for the initial login.
The database is local to the webserver and the web server is remote for the user.
TL:DR This logon is not a peer logon as the postgres *nix user.
It's a gap in the install. A manual step will always be required to add a password for postgres for anyone wanting to use the interface for initial USER/ROLE creation. It would be nice to have had this opportunity in the setup script.
I suppose it is expected that most administrators would also add other users/roles at this time and these would be supplied to the users. Changes to config files would still be managed. They are not getting shell access.
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 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
A few days ago I started working with firebird on opensuse. When I try open the database by using monodevelop(C#), I get the error message:
"access to database is denied by server administrator"
How can I solve this?
I am using firebird 2,5, opensuse 13.1, and monodevelop.
You are trying to access a database in a location that is not allowed by the server configuration. There are two potential causes:
The value(s) of DatabaseAccess in firebird.conf do not include or explicitly deny the current location of the database.
To fix this you either need to configure an alias and use the alias to connect, move the database to one of the allowed folders, or add an additional location to the configuration entry
the firebird user (the user running the server process) does not have access to the database file.
To fix this you need to make sure that the firebird user of the server process (if connecting through the Firebird server), or your own user (if using embedded) has sufficient access rights to the database.
See also http://www.firebirdfaq.org/faq39/ and http://ibexpert.net/ibe/index.php?n=Doc.ConfiguringFirebird#DatabaseAccess