Users - Firebird

Users are the recipients of permissions and the losers when permissions are revoked. A user can be a user that is defined in the security database, a UNIX account or group, a special user, or a database object.

• Roles as users:When a role is being awarded privileges, it is a user. Once a role has been granted the required privileges to objects, it “changes hats” and becomes a privilege that can be granted to some other types of users. When the login to the database is done under that role, those users assume the privileges that were awarded to the role.
• Views as users:Views need permissions to access tables, other views, and stored procedures.
• Procedures and triggers as users: A stored procedure that accesses tables and views and executes other procedures needs permissions on those objects. A trigger that executes procedures needs permissions on those and also on any tables or views it accesses other than the table that it belongs to.

Special Users

The SYSDBA user has special rights to all databases and the objects within them, regardless of which user owns them. Furthermore, on operating systems that implement the concept of a Superuser—a user with root or locksmith privileges—such a user also has full access and destructive rights access to all databases and their objects if it logs in under the root ID. For more details, refer to the section “The POSIX Hole” in the previous chapter.

Initially, an object’s creator, its owner, is the only user other than SYSDBA or the Superuser that has access to an object (table, view, stored procedure, or role) or can permit other users to access it. Either user can then start off “chains” of permissions by granting other users the right to grant privileges. This right is optionally passed on by appending the WITH GRANT OPTION qualifier to the permission.

In a similar manner, SYSDBA or the owner of a role can optionally qualify a role privilege that it grants to a user as WITH ADMIN OPTION. However, a privilege assumed by a user that logs in under a role does not inherit WITH GRANT OPTION authority from the role. More on this later.

The PUBLIC User

PUBLIC is a user that stands for all users in the security database. It does not refer to or comprise stored procedures, triggers, views, or roles.

If multiple databases are running on the server, granting large packages of privileges to PUBLIC might save a lot of typing, but it is fairly easy to grant privileges by mistake to users that should not have them.

Embedded Servers

It is strongly recommended that databases intended for use in the embedded server be tightly protected with permissions. The user of an embedded server on Windows is not authenticated, by design, since there is no security database! As no user verification is performed on GRANT statements, permissions statements can be accepted for a “mock user” (i.e., a made-up name that your application uses for connection to the database via the embedded client).