You have a few choices in how to do this.

You can either upgrade your users to RDB$ADMIN role rights (not recommended) or you can grant the user to have rights to a view that gets it's data from a stored procedure that connects back to the database in a separate connect/transaction as a user that is a member of the RDB$ADMIN role - and you setup the database triggers so that the database prevents that specialized user from connecting to the database from any application other than the firebird server and the servers ip address (you can get this information from the mon$ tables).

This is a better way, but, due to someone being able to read the DDL, they may get a way to abuse your system by reading the system tables and getting the special users username/password/role.   

It is better to have them connect to a different, more secure database, with a low end user account that can only run that one view, then that view, connects back to the primary database to get the information.   This keeps all the private DDL information away from anyone who has read access to the system tables.   So, even if they can read the metadata of the primary database, it does not give them the right to read the metadata of the second database, thus keeping the private credentials away from the user.

Also, you will need to filter the output to not show these hidden/system connections to the regular user.

There are a few other ways, but, they rely upon OS specific tricks that are a bit too complicated to mention in a simple email.

best regards

Dalton