Procfs: Difference between revisions

From dankwiki
No edit summary
Line 13: Line 13:


procfs since Linux 3.3 accepts a mount option <tt>hidepid</tt>, taking one of three values:
procfs since Linux 3.3 accepts a mount option <tt>hidepid</tt>, taking one of three values:
* 0: everyone may access all <tt>proc/PID` directories
* 0: everyone may access all <tt>proc/PID</tt> directories
* 1: users can only access their own <tt>proc/PID</tt> directories
* 1: users can only access their own <tt>proc/PID</tt> directories
* 2: users can only *see* their own <tt>proc/PID</tt> directories
* 2: users can only *see* their own <tt>proc/PID</tt> directories

Revision as of 09:40, 11 October 2019

procfs began life (on Solaris?) as a virtual filesystem dedicated to exporting process information. Over time, it has grown substantially on any number of operating systems. It is pretty much a required interface on Linux, and strongly recommended on Solaris and FreeBSD.

proc/PID

Each entity associated with a non-zero PID (this includes most kernel threads) has a corresponding toplevel procfs directory named by its PID (e.g. when using systemd as init and mounting procfs at /proc, systemd's primary process is described by /proc/1 (the process only appears in procfs mounts within the same PID namespace). One of the entries is proc/PID/task, a directory which contains the threads making up the process, using the TID as name:

[schwarzgerat](1) $ grep ^Threads: /proc/`pidof rtorrent`/status
Threads:	3
[schwarzgerat](0) $ ls /proc/`pidof rtorrent`/task
4282  4283  4309
[schwarzgerat](0) $ 

procfs since Linux 3.3 accepts a mount option hidepid, taking one of three values:

  • 0: everyone may access all proc/PID directories
  • 1: users can only access their own proc/PID directories
  • 2: users can only *see* their own proc/PID directories

Linux 3.3 also introduced the gid parameter, which specifies a group ID. Members of this group are exempted from hidepid restrictions.

proc/PID/stat sucks

/proc/PID/stat

See Also