Subject | RE: [firebird-support] Re: Firebird database seems to influence multi user ability |
---|---|
Author | Svein Erling Tysvær |
Post date | 2014-12-09T14:33:03Z |
>I have been an interbase guy about fifteen years ago and loved to see it go open source. I used to work with Paul Beach (Hello, if you're here,Paul)Yes, Paul Beach is still here, he’s working with other InterBase and Firebird experts at IB Phoenix. Here you can see who they are: http://www.ibphoenix.com/about/contact
>another mystery to me. First of all, I was using SYSDBA for all of my actions. It worked with "masterkey"!Well, I could agree that no one ought to run with the default password. However, I would say that software should not automatically change the Firebird password. It is fine if your system is the only system on your computer using Firebird, but let’s say there already exists another program on your computer that uses Firebird, you install your program and change the password, then you may risk that the original program no longer works. Hence, I’d say some kind of intelligence ought to be present when installing Firebird, and leaving this responsibility to a human administrator of the machine is one common way to do it (it may vary depending on what your system does). A system ought to tell the users how to install Firebird and change password. Of course, they can also provide a Firebird installer if they want to. If they do, they could change the password when installing Firebird, but never do any automatic change of the SYSDBA password to an existing system.
>As far as I remember this should be changed in any serious software, shouldn't it?
Using the default password makes your database vulnerable to anyone with access to the database, but generally you should limit who has access to your database and only give access through aliases so that no one knows where the database is physically stored. Then the vulnerability will be limited to those who have access. Of course, SYSDBA can normally look at, modify or delete any object. In many cases this will be very bad, in other cases it might not matter equally much. If anyone gets physical access to your Firebird database, then you may consider all sensitive data lost. Put a copy of the database on any machine, install Firebird and you get access with the default password.
>Another thing is that I was looking into the tables and missed RDB$user. The table just is not there. Did that change recently?Are you sure that RDB$USER was a table? I’m used to users being defined in the Firebird server itself (probably stored in security2.fdb in your case, 15 years ago I think it will have been isc4.gdb), whereas their rights to any object in a database is stored in the database itself (probably in RDB$USER_PRIVILEGES, although I must admit I don’t know). I don’t quite understand what an RDB$USER table in your own database should be used for, although, again, I must admit that my knowledge of the system tables are limited to what I’ve used myself (which doesn’t include RDB$USER).
HTH,
Set