Re: PR_SET_NO_NEW_PRIVS still in need of three trailing 0L arguments?

[Alejandro Colomar <alx+linux-man@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

Hi Aaron,

> Date: 2026-10-27 00:32:29-0400
> From: Aaron Rainbolt <arraybolt3@gmail.com>
>
> At one point, prctl always required five arguments. At some point
> thereafter, it became a variadic function. Some of the PR_*(2const) man
> pages recognize it as a variadic function, such as
> PR_SET_DUMPABLE(2const), which states that you can use something like
> `prctl(PR_SET_DUMPABLE, 1L);` without problems. On the other hand,
> PR_SET_NO_NEW_PRIVS(2const) documents the only allowable method of use
> as `prctl(PR_SET_NO_NEW_PRIVS, 1L, 0L, 0L, 0L);`, which looks like the
> non-variadic form is still being assumed.
> 
> Is there some historical reason that three trailing 0L arguments must
> or at least should be passed?

The kernel just behaves that way:

	alx@devuan:~/src/linux/linux/master$ grepc prctl . | sed -n /PR_SET_DUMPABLE/,/\\bcase\\b/p;
		case PR_SET_DUMPABLE:
			if (arg2 != TASK_DUMPABLE_OFF && arg2 != TASK_DUMPABLE_OWNER) {
				error = -EINVAL;
				break;
			}
			task_exec_state_set_dumpable(arg2);
			break;

		case PR_SET_UNALIGN:
	alx@devuan:~/src/linux/linux/master$ grepc prctl . | sed -n /PR_SET_NO_NEW_PRIVS/,/\\bcase\\b/p;
		case PR_SET_NO_NEW_PRIVS:
			if (arg2 != 1 || arg3 || arg4 || arg5)
				return -EINVAL;

			task_set_no_new_privs(current);
			break;
		case PR_GET_NO_NEW_PRIVS:

I don't know why it behaves differently for those, though.  Maybe those
conditions could be relaxed.

If you're interested in it, I suggest CCing the relevant kernel
maintainers in this discussion, and asking them whether they're okay
lifting those requirements.


Have a lovely day!
Alex

> Or is the manpage simply out of date? I'd
> be happy to send patches for this and other prctl functions that are
> mistakenly non-variadic if there is a need to. If there is a historical
> reason to pass three trailing 0L arguments, maybe that reason could be
> documented.
> 
> Thanks for your time,
> 
> --
> Aaron



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]