Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

location of users lists /DB permission/ [CORE685] #1050

Closed
firebird-automations opened this issue Sep 17, 2003 · 22 comments
Closed

location of users lists /DB permission/ [CORE685] #1050

firebird-automations opened this issue Sep 17, 2003 · 22 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pcisar

Is duplicated by CORE1856
Is duplicated by CORE3273
Is duplicated by CORE1996
Relate to CORE3368
Is duplicated by CORE3783
Is related to QA621

Votes: 9

SFID: 807971#⁠
Submitted By: pcisar

here is 2 possible ways :
1.relocate user list from isc4.gdb to user DB
2.create additional user list in user DB and secondary
authentification mechanism per database

it's needed when peoples don't want share structure of
created database with other include SYSDBA.

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-07-24 18:42
Sender: dimitr
Logged In: YES
user_id=61270

Comment by Osama ALASSIRY:

One huge problem is that by moving a database file to
another server, you can access and modify all the data
in the database using the other server's sysdba account.

A standalone database would be one that does not use
any information from security.fdb, it includes its own
users table and will not respond to the users in
security.fdb

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Component: Security [ 10071 ]

assignee: Dmitry Yemanov [ dimitr ]

SF_ID: 807971 =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 [ 10048 ]

SF_ID: 807971 =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

assignee: Dmitry Yemanov [ dimitr ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Gregory Kotsaftis (gregkotsaftis)

This is a must!

Nobody should be able to copy the database file to another computer, with another
firebird installation and another sysdba user.
The same applies for backup/restore jobs, a backup up of the original db should not
be restored to another installation without the original sysdba passwd.

I hope this will be resolved in v3.0

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10709 ] => Firebird [ 15123 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE1856 [ CORE1856 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Dimitris Panidis (dpanidis)

Thanks for the answer. However, I have a hard time understanding both workarounds. No1 says to "relocate user list from isc4.gdb to user DB". From what I saw, isc4.gdb is the security database of Interbase, from what little I know, the security db for Firebird is security2.fdb. In any case, how can I disable and bypass the built in security mechanism of this database and place it on my own database file?
As far as the second suggestion, "create additional user list in user DB and secondary authentication mechanism per database", I already have extra application level authentication but how can I prevent people from copying the entire database file, and opening it from their own fresh installation? Any help on the above will be greatly appreciated

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

They are not workarounds but possible implementation suggestions to be considered by the FB developers.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

Fix Version: 3.0.0 [ 10048 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE3273 [ CORE3273 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE1996 [ CORE1996 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE3368 [ CORE3368 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE3783 [ CORE3783 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I'm closing this one as resolved but keeping CORE3368 open until all its subtasks are completed.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA621 [ QA621 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA621 [ QA621 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue relate to QA621 [ QA621 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue relate to QA621 [ QA621 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA621 [ QA621 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants