Procfs - revision history

Dank: /* proc/PID */

2023-06-27T04:21:02Z

proc/PID

← Older revision		Revision as of 04:21, 27 June 2023
Line 13:		Line 13:
	Since time immemorial, tools like <tt>ps</tt> have enumerated processes via walking procfs's dentries when possible.		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		* 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
			* 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.		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 ~~will generally~~ no longer be able to access your own <tt>/proc/PID</tt>.		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>===		===<tt>proc/PID/loginuid</tt>===

Dank at 23:56, 26 June 2023

2023-06-26T23:56:46Z

← Older revision		Revision as of 23:56, 26 June 2023
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.

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

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

Dank: /* proc/PID */

2019-11-08T09:54:40Z

proc/PID

← Older revision		Revision as of 09:54, 8 November 2019
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===

Dank: /* proc/PID/stat sucks */

2019-10-11T18:39:11Z

proc/PID/stat sucks

← Older revision		Revision as of 18:39, 11 October 2019
Line 84:		Line 84:
	</pre>		</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==		==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

Dank: /* proc/PID/stat sucks */

2019-10-11T16:05:45Z

proc/PID/stat sucks

← Older revision		Revision as of 16:05, 11 October 2019
Line 46:		Line 46:
	</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>

Dank: /* proc/PID/stat sucks */

2019-10-11T15:08:25Z

proc/PID/stat sucks

← Older revision		Revision as of 15:08, 11 October 2019
Line 20:		Line 20:

	===<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:

Dank: /* proc/PID/stat sucks */

2019-10-11T14:59:24Z

proc/PID/stat sucks

← Older revision		Revision as of 14:59, 11 October 2019
Line 84:		Line 84:
	</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>, 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

Dank: /* proc/PID/stat sucks */

2019-10-11T14:58:22Z

proc/PID/stat sucks

← Older revision		Revision as of 14:58, 11 October 2019
Line 67:		Line 67:
	</pre>		</pre>

	Good, I guess?		Good, I guess? Gotta love that silent truncation to <tt>TASK_COMM_LEN</tt> bytes (16 as of Linux 5.3.5).

	To remedy this and other problems, <tt>proc/PID/status</tt> also exists, reproducing most of the information from <tt>stat</tt> using newline-delimited key-value pairs. The process name here is backslash-escaped. Let's return to our three friendly processes:		To remedy this and other problems, <tt>proc/PID/status</tt> also exists, reproducing most of the information from <tt>stat</tt> using newline-delimited key-value pairs. The process name here is backslash-escaped. Let's return to our three friendly processes:

Dank: /* proc/PID/stat sucks */

2019-10-11T14:50:46Z

proc/PID/stat sucks

← Older revision		Revision as of 14:50, 11 October 2019
Line 60:		Line 60:
	echo "$$ Changed my name to $1!"		echo "$$ Changed my name to $1!"
	suck		suck
	[schwarzgerat](0) $ chmod 755 p && ./p ~~bigdumb (sometimes not, though; see below):sackofshit~~		[schwarzgerat](0) $ chmod 755 p && ./p bigdumbsackofshit
	30819 c bash e (bash)		30819 c bash e (bash)
	30819 Changed my name to bigdumbsackofshit!		30819 Changed my name to bigdumbsackofshit!

Dank: /* proc/PID/stat sucks */

2019-10-11T14:49:22Z

proc/PID/stat sucks

← Older revision		Revision as of 14:49, 11 October 2019
Line 20:		Line 20:

	===<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 acceptable.		<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.

	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: