Please withdraw for now. sys/exec.h change doesn't fit well in userland.
Thanks. On Mon, Mar 22, 2021 at 11:05:06AM +0100, Sebastien Marie wrote: > Hi, > > The following diff tries to simplify a bit the entanglement of namei > data and execve(2) syscall. > > Currently, when called, sys_execve() might doing recursive calls of > check_exec() with a shared `struct nameidata' (`ep_ndp' inside > `struct exec_package'). > > I would like to disassociate them, and make check_exec() to "own" the > `struct nameidata' data. execve(2) is complex enough, no needs to adds > namei() complexity inside. > > check_exec() will initialize nameidata, call namei() (as now), extract > useful information for the caller (only the vnode and the > command-name, returned via exec_package struct), and free other namei > ressources. > > To proceed, it only needs to know the wanted path (to properly init > `nd' with NDINIT). > > As the call of check_exec() could be recursive (when scripts are > involved), the path could come from: > - directly from sys_execve() via SCARG(uap, path) (from userspace) > - from exec_script_makecmds() via the shellname (from systemspace) > > In `struct exec_package', I opted to reuse `ep_name' for passing the > path: it is what sys_execve() is already doing at first call. Later it > is only used for construct the fake-args list in > exec_script_makecmds(), and it could being overrided after that (and > restored on error). I reordered them a bit to make it fit. > > Eventually I could also introduce a new struct field for the wanted > path. > > `ep_segflg' is introduced to mark if ep_name comes from UIO_USERSPACE > or UIO_SYSSPACE. it will be used by NDINIT() in check_exec(). > > `ep_comm' is the other information (with ep_vp) wanted in result of > check_exec() call. it will be copied to `ps_comm'. > > > Comments or OK ? > -- > Sebastien Marie
