On 03/26/14 13:23, Tony Whyman wrote: > 1, Requiring access to the security database is a change in behaviour > from Firebird 2.1 and breaks any implementation that relied on this.
If you do not use -user switch in isql, security database is no accessed and not needed: # ./isql -user sysdba -pas masterkey employee Database: employee, User: sysdba SQL> If I remove security database: # ./isql -user sysdba -pas masterkey employee Statement failed, SQLSTATE = 08001 I/O error during "open" operation for file "/opt/firebird.CS.2.5/security2.fdb" -Error while trying to open file -No such file or directory Use CONNECT or CREATE DATABASE to specify a database SQL> But it does not prevent to: # ./isql employee Database: employee SQL> I agree that checking login/password in absolutely useless with embedded access, this is fixed in FB3. > 2. What's wrong with respectiing the FIREBIRD environment variable > setting? In the past this worked consistently across all platforms and > allowed both test environments to be readily set up and environments > where the user did not have root access. Some OSes (as far as I know Debian too) use non-standard for firebird but standard for OS files placement. That makes FIREBIRD environment variable almost useless - what is FB root when utilities are placed in /usr/bin but security database to /var/lib/firebird/2.5/system? > 3. I am trying to think of a security threat that is being countered by > ignoring the environment variable but I can't think of one. > > - normal Unix permissions protect access to Firebird Databases > independent of the security database. > - the role of the security database is to control server based access to > remote users and local users that do not have local access rights to a > database. yes > 4. The embedded server should allow a user to access common databases > when the user is in the firebird group and any local databases that they > own. However, forcing a user to be a member of the firebird group in > order to access their own databases potentially allows them access to > common databases (including the security database) to which they would > not have otherwise been granted access. This appears to be a serious > disbenefit resulting from the change in behaviour. As I've already shown embedded users are not enforced to use security database to access own databases. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
