Is mounting /proc with "hidepid=2" recommended with RHEL7 and later?

Solution Verified - Updated -

Red Hat Insights can detect this issue

Proactively detect and remediate issues impacting your systems.
View matching systems and remediation


  • Red Hat Enterprise Linux 7 and later


  • When mounting /proc with hidepid=2 mount option, I can see AVC denies related to NetworkManager or sssd, e.g.

    type=PROCTITLE msg=audit(01/10/2022 15:35:30.024:31) : proctitle=/usr/sbin/NetworkManager --no-daemon 
    type=SYSCALL msg=audit(01/10/2022 15:35:30.024:31) : arch=x86_64 syscall=kill success=no exit=EACCES(Permission denied) a0=0x4a1 a1=SIG0 a2=0x0 a3=0x0 [...] comm=NetworkManager exe=/usr/sbin/NetworkManager subj=system_u:system_r:NetworkManager_t:s0 key=(null) 
    type=AVC msg=audit(01/10/2022 15:35:30.024:31) : avc:  denied  { signull } for  pid=1148 comm=NetworkManager scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0 


    type=PROCTITLE msg=audit(01/10/2022 15:35:32.650:49) : proctitle=/usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files 
    type=SYSCALL msg=audit(01/10/2022 15:35:32.650:49) : arch=x86_64 syscall=openat success=no exit=ENOENT(No such file or directory) [...] comm=sssd_nss exe=/usr/libexec/sssd/sssd_nss subj=system_u:system_r:sssd_t:s0 key=(null) 
    type=AVC msg=audit(01/10/2022 15:35:32.650:49) : avc:  denied  { sys_ptrace } for  pid=1213 comm=sssd_nss capability=sys_ptrace  scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:sssd_t:s0 tclass=capability permissive=0 


Stop using hidepid=2 (hidepid=1 is known to not work at all). If you were using hidepid=2, make sure to remove gid=XXX as well.

RHEL systemd Engineering considers that using hidepid=2 is not recommended at all on RHEL7 and later due to many reasons exposed below.

The main purpose of the hidepid= mount option is the ability to not disclose information (to the given user) about processes of other users running on the same system.

There are at least three problems that arise when this option is used.

First, the proc filesystem mount is a global entity that exists inside a given mount namespace. Hence, if any mount option is used on proc filesystem mount then it affects every process which runs in the same filesystem namespace. In many cases this is not desirable and causes further issues.

Previous issue leads to the second problem. If hidepid= option is used then some system services like (PolicyKit or D-Bus) are not able to query information about the clients which are connecting to them. This is because all these services run as non-privileged (i.e. euid != 0) and hence don't see needed information in /proc/[pid] directory of the client, unless the client runs under the same uid which is never the case (at least for PolicyKit and D-Bus).

Last problem, that we would like to highlight is potential information leak and false sense of security that hidepid= provides. Information (PID numbers, command line arguments, UID and GID) about system services are tracked by systemd. By default this information is available to everyone to read via systemd's D-Bus interface. When hidepid= option is used systemd doesn't take it into consideration and still exposes all this information at the API level.

Because of these issues we don't recommend at this time using hidepid= option on RHEL7 and later.

This guidance may change in future as we work on improvements to kernel's proc filesystem implementation as well as on systemd and other system services (e.g. PolicyKit and D-Bus) that are negatively affected by enabling hidepid= mount option.

Root Cause

hidepid=1 or hidepid=2 are not compatible with how systemd manages the system.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.