Firebird 4.0: Disabling PUBLIC Role Membership to Prevent Accidental Public Access

Answer to the Question

In Firebird 4.0 the PUBLIC role is built‑in and cannot be disabled or revoked. The only thing you can control is the set of privileges that are granted to PUBLIC. To prevent accidental public exposure you must revoke those privileges and, if your applications rely on implicit PUBLIC rights, replace them with explicit roles that you grant to users.

Why PUBLIC Cannot Be Disabled

• PUBLIC is a system role automatically granted to every user by the server engine.
• There is no configuration parameter in firebird.conf that turns PUBLIC off.
• Only the privileges that are granted to PUBLIC can be revoked with REVOKE.

Practical Steps for Your Environment

1. Audit Existing PUBLIC Grants

   Run the following in isql to list all objects that currently have PUBLIC privileges:

   SHOW GRANTS FOR PUBLIC;
   

   Document which privileges (SELECT, INSERT, UPDATE, DELETE, EXECUTE) appear.

2. Revoke Unnecessary PUBLIC Privileges

   For each object, revoke the privilege you want to restrict:

   REVOKE SELECT ON <table> FROM PUBLIC;
   REVOKE EXECUTE ON <procedure> FROM PUBLIC;
   

   Repeat until no unwanted PUBLIC rights remain.

3. Create Explicit Roles

   Define roles that encapsulate the privileges your applications need:

   CREATE ROLE app_reader;
   GRANT SELECT ON <table> TO app_reader;
   

   Grant the role to the intended users:

   GRANT app_reader TO <user>;
   

4. Test in a Staging Environment

   Connect as a user that only has the explicit role and confirm that the application behaves as expected. Verify that a user without the role cannot access the object.

5. Adjust RemoteAccess If Needed

   Setting RemoteAccess=no in firebird.conf limits the server to local connections only. It does not alter PUBLIC privileges, so use it as a network hardening step in addition to the privilege changes.

Key Considerations

• If an existing application uses implicit PUBLIC rights (e.g., a SELECT on a table that was granted to PUBLIC), revoking those rights will break the app. In that case, create a role that inherits PUBLIC’s privileges and grant that role to the user.
• Always back up the database before making bulk REVOKE operations.
• After changes, run SHOW USER to verify role memberships and ensure that PUBLIC still appears automatically.

Missing Diagnostic Detail

To refine this recommendation, could you share which specific privileges (e.g., SELECT on EMPLOYEES, EXECUTE on PROC_UPDATE) are currently granted to PUBLIC in your database? This will help determine whether a role‑based replacement is necessary or if revoking the privilege alone suffices.