Procfs

(4 intermediate revisions by the same user not shown)

Line 13:

Since time immemorial, tools like <tt>ps</tt> have enumerated processes via walking procfs's dentries when possible.

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 four values:

* 0: everyone may access all <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

* 4: users can only see directories of processes they can [[ptrace]]

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

Note that if you start a process as one user, and change to another user using e.g. <tt>setuid(2)</tt>, you might no longer be able to access your own <tt>/proc/PID</tt>.

===<tt>proc/PID/loginuid</tt>===

Note that this is only present when <tt>CONFIG_AUDIT</tt> is enabled in the kernel configuration. Audit doesn't have to be enabled, and auditd doesn't need to be running, but without that option, no <tt>loginuid</tt> for you.

===<tt>proc/PID/stat</tt> sucks===

Line 46:

Line 52:

</pre>

We start at the lparen following whitespace following digits. But where do we end? *There is no valid delimiter*. Even if we don't care about the name of the process, and just want to know its state ('S'leeping in all three cases above), we can't identify where the next token begins. Any potential delimiter can be encoded into a filename under this scheme. Together with the varying fields over the years, one must lex backwards from the right, since the common (and most important) fields are in the front.

We start at the lparen following whitespace following digits. But where do we end? <i>There is no valid delimiter</i>. Even if we don't care about the name of the process, and just want to know its state ('S'leeping in all three cases above), we can't identify where the next token begins. Any potential delimiter can be encoded into a filename under this scheme. Together with the varying fields over the years, one must lex backwards from the right, since the common (and most important) fields are in the front.

What, you ask? Couldn't we read <tt>proc/PID/comm</tt> and thus know the exact match to expect? Unfortunately, a process (or even thread) can change its "comm value". According to the <tt>proc(5)</tt> man page, <tt>stat</tt>'s second field reproduces the name of the *executable*, and thus a process which had changed its comm value would not facilitate sane lexing. The documentation is incorrect:

What, you ask? Couldn't we read <tt>proc/PID/comm</tt> and thus know the exact match to expect? Unfortunately, a process (or even thread) can change its "comm value". According to the <tt>proc(5)</tt> man page, <tt>stat</tt>'s second field reproduces the name of the <i>executable</i>, and thus a process which had changed its comm value would not facilitate sane lexing. The documentation is incorrect:

<pre>

Line 84:

Line 90:

</pre>

Unfortunately, <tt>proc/PID/status</tt> cheerfully leaves out several fields from <tt>stat</tt>, including <tt>flags</tt>, so it's like what was the point of that exactly. Ugh.

Unfortunately, <tt>proc/PID/status</tt> cheerfully leaves out several fields from <tt>stat</tt>, including <tt>flags</tt> and all the timing information, so it's like what was the point of that exactly. Ugh.

==See Also==

* The [[sysfs]] page

* UNIX V8 [http://man.cat-v.org/unix_8th/4/proc proc(4)] man page

Procfs: Difference between revisions

Dank (talk | contribs)

@@ Line 13: / Line 13: @@
 Since time immemorial, tools like <tt>ps</tt> have enumerated processes via walking procfs's dentries when possible.
-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 four values:
 * 0: everyone may access all <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
+* 4: users can only see directories of processes they can [[ptrace]]
 Linux 3.3 also introduced the <tt>gid</tt> parameter, which specifies a group ID. Members of this group are exempted from <tt>hidepid</tt> restrictions.
+Note that if you start a process as one user, and change to another user using e.g. <tt>setuid(2)</tt>, you might no longer be able to access your own <tt>/proc/PID</tt>.
+===<tt>proc/PID/loginuid</tt>===
+Note that this is only present when <tt>CONFIG_AUDIT</tt> is enabled in the kernel configuration. Audit doesn't have to be enabled, and auditd doesn't need to be running, but without that option, no <tt>loginuid</tt> for you.
 ===<tt>proc/PID/stat</tt> sucks===
@@ Line 46: / Line 52: @@
 </pre>
-We start at the lparen following whitespace following digits. But where do we end? *There is no valid delimiter*. Even if we don't care about the name of the process, and just want to know its state ('S'leeping in all three cases above), we can't identify where the next token begins. Any potential delimiter can be encoded into a filename under this scheme. Together with the varying fields over the years, one must lex backwards from the right, since the common (and most important) fields are in the front.
+We start at the lparen following whitespace following digits. But where do we end? <i>There is no valid delimiter</i>. Even if we don't care about the name of the process, and just want to know its state ('S'leeping in all three cases above), we can't identify where the next token begins. Any potential delimiter can be encoded into a filename under this scheme. Together with the varying fields over the years, one must lex backwards from the right, since the common (and most important) fields are in the front.
-What, you ask? Couldn't we read <tt>proc/PID/comm</tt> and thus know the exact match to expect? Unfortunately, a process (or even thread) can change its "comm value". According to the <tt>proc(5)</tt> man page, <tt>stat</tt>'s second field reproduces the name of the *executable*, and thus a process which had changed its comm value would not facilitate sane lexing. The documentation is incorrect:
+What, you ask? Couldn't we read <tt>proc/PID/comm</tt> and thus know the exact match to expect? Unfortunately, a process (or even thread) can change its "comm value". According to the <tt>proc(5)</tt> man page, <tt>stat</tt>'s second field reproduces the name of the <i>executable</i>, and thus a process which had changed its comm value would not facilitate sane lexing. The documentation is incorrect:
 <pre>
@@ Line 84: / Line 90: @@
 </pre>
-Unfortunately, <tt>proc/PID/status</tt> cheerfully leaves out several fields from <tt>stat</tt>, including <tt>flags</tt>, so it's like what was the point of that exactly. Ugh.
+Unfortunately, <tt>proc/PID/status</tt> cheerfully leaves out several fields from <tt>stat</tt>, including <tt>flags</tt> and all the timing information, so it's like what was the point of that exactly. Ugh.
 ==See Also==
 * The [[sysfs]] page
 * UNIX V8 [http://man.cat-v.org/unix_8th/4/proc proc(4)] man page