PR_SET_NO_NEW_PRIVS still in need of three trailing 0L arguments?

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

Hi Aaron,

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

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