Are there any posibilities to prevent users invoke \du command in Postgres ?

  • 2
    In a nutshell: you can not.
    – user1822
    Jan 24, 2022 at 6:50

1 Answer 1


What are Users doing in your database, running psql directly at all?
Unless your security model is exceedingly good, this is hugely dangerous.

Users should not be allowed anywhere near the "raw" database, and especially not anywhere near the Production one!

  • I have a user that can only login (GRANT CONNECT) to a database and to perform operation using SET ROLE to other group (eg real only ROLE). But this user also member of group rw group. is it possible to hide this user from it groups ? I use this scenario in case that the user/password from the user is revealed and to prevent SQL Injection (by hiding groups) Jan 24, 2022 at 22:44
  • More detail, please. "Connect and then set role" is a [very] good start, BTW. What is the "group rw group"? If this membership is causing you problems, what would happen if you removed this user from this group? SQL Injection and Security are two different problems.
    – Phill W.
    Jan 25, 2022 at 9:44
  • I have 3 ROLES, user_a, user_b and user_c. ROLE user_a is only role that can login (GRANT CONNECT ON DATABASE). ROLE user_b is "group" (NO LOGIN ROLE) and able to read in all schema. ROLE user_c is also 'group" and able to read and write on some table. user_a is member of user_b and _user_c, and using SET ROLE to act as user_b and user_c. If there are some bug in the program and the password from user_a revealed, the attacker will then easily switch ROLE. So if I can prevent user invoke \du (or by SQL query) then I guess it will be more safe Jan 26, 2022 at 6:01
  • Your concern is mainly about password security. That's a whole other Ball Game and largely boils down to discipline in your Developer community. For example, you don't want people writing credentials out in plain text into an application log file - don't laugh, I've seen it. Also, you're not factoring in the "public" role/group. What permissions are granted to /that/? Any of your accounts would automatically "inherit" these.
    – Phill W.
    Jan 26, 2022 at 14:34
  • Yes, I also remove the PUBLIC ROLE from public schema too, considering search_path, user_a also create with NOINHERIT option, so the user_a can only CONNECT to a database. I just want to avoid" sloppy" developer with better database security. Yes using dorking will easily found credential password. The other approach are using each ROLES can LOGIN and has each password. But using this approach will need more resources to support connection process. Jan 26, 2022 at 22:26

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .