Anonymous

Procfs: Difference between revisions

From dankwiki
364 bytes added ,  04:54, 8 November 2019
 
(4 intermediate revisions by the same user not shown)
Line 18: Line 18:
* 2: users can only *see* their own <tt>proc/PID</tt> directories
* 2: users can only *see* their own <tt>proc/PID</tt> directories
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.
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.
===<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===
===<tt>proc/PID/stat</tt> sucks===
<tt>/proc/PID/stat</tt> contains a mélange of data, though exactly which data depends on precise kernel version. The proc(5) manpage describes them in terms of <tt>scanf</tt> conversion operators, which generally lacks rigor due to [[C]] numeric types having different ranges on different implementations. This would all be gross, but fundamentally acceptable.
<tt>/proc/PID/stat</tt> contains a mélange of data, though exactly which data depends on precise kernel version. The <tt>proc(5)</tt> manpage describes them in terms of <tt>scanf</tt> conversion operators, which generally lacks rigor due to [[C]] numeric types having different ranges on different implementations. This would all be gross, but fundamentally acceptable.


No, the real shit on this sandwich is that it is provably impossible to rigorously delineate the second field, even with a pushdown automata:
No, the real shit on this sandwich is that it is provably impossible to rigorously delineate the second field, even with a pushdown automata:
Line 46: Line 49:
</pre>
</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>
<pre>
Line 84: Line 87:
</pre>
</pre>


Unfortunately, <tt>proc/PID/status</tt> cheerfully leaves out several fields from <tt>stat</tt>, including <tt>flags</tt>.
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==
==See Also==
* The [[sysfs]] page
* The [[sysfs]] page
* UNIX V8 [http://man.cat-v.org/unix_8th/4/proc proc(4)] man page
* UNIX V8 [http://man.cat-v.org/unix_8th/4/proc proc(4)] man page