Re: [DISCUSSION] proposed mctl() API

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 29 May 2025 15:43:26 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

>
> madvise()
>
> ...
>
> process_madvise()
>
> ...
>
> prctl()
>
> ...
>

Yeah.  I think there has always been an attitude "ooh, new syscalls are
scary and I probably need permission from someone so let's graft it
onto something which is already there and hope nobody notices".

New syscalls are super easy and are cheap - it's just a table entry! 
If it makes sense as a standalone thing, do that.

> The proposed interface is simply:
> 
> int mctl(int pidfd, int action, unsigned int flags);

Well, why `flags'?  One could even add a syscall per operation. 
Debatable.

> Of course, security will be of utmost concern (Jann's input is important
> here :)
> 
> We can vary security requirements depending on the action taken.
> 
> For an initial version I suggest we simply limit operations which:
> 
> - Operate on a remote process
> - Use the MCTL_SET_DEFAULT_EXEC flag
> 
> To those tasks which possess the CAP_SYS_ADMIN capability.
>
> This may be too restrictive - be good to get some feedback on this.

Permissions needs careful consideration on a case-by-case basis.
Clearly in many cases, user A should be able to manipulate user A's
mm's.

And if different modes of mctl() end up with different permission
structures, one wonders why everything was clumped under the same
syscall!  mctl() becomes "prctl() for memory".

Anyway, fun discussion.  I'm with willy ;)