PR_SET_NO_NEW_PRIVS still in need of three trailing 0L arguments?

PR_SET_NO_NEW_PRIVS still in need of three trailing 0L arguments?

[Aaron Rainbolt]

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

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? 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Alejandro Colomar]

[-- 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 --]