Sebastien Marie <sema...@online.fr> wrote:
> On Sun, Mar 08, 2020 at 12:04:07AM +0000, int3resting27 wrote:
> > Example program:
> >
> > #include <unistd.h>
> > #include <stdio.h>
> > int main(int argc, char **argv) {
> > char *const args[] = { "Z", NULL, };
> > char *const env[] = { NULL, };
> >
> > if (argv[0][0] == 'Z') {
> > printf("success\n");
> > return (0);
> > }
> >
> > unveil(argv[0], "x");
> > pledge("exec", "stdio rpath");
> > execve(argv[0], args, env);
> > }
> >
> > Expected behavior: execve's itself then prints "success" and exits
> > Actual behavior: killed by SIGABRT when calling execve. It doesn't seem
> > to be pledge's usual SIGABRT because nothing gets logged to syslog like
> > pledge is supposed to do and core isn't dumped
>
> unveil(2) setting in the process isn't cleared on execve(2) due to
> execpromises
> use. see https://github.com/openbsd/src/blob/master/sys/kern/kern_exec.c#L530
>
> I am unsure if it is intented or not. but at some point, it has been discussed
> if unveil(2) should be inherited or not (comments in kern_exec.c are trace of
> that).
>
> For now, you need to unveil(2) all files required to reexecute your file, or
> not
> use execpromises.
Don't use execpromises.
The code for it will probably be deleted.
There were all sorts of mocking words about pledge not being carried over
through execve, so I provided a tool that would do it.
I tried to do it for $PAGER and $EDITOR in many programs. It is
basically impossible to handle symbolic link traversal, as well as
the potential for the sub-program to want to do more. And then get
killed. So I introduced "error", and found out that some editors fail
just as hard as having been killed when they receive an unexpected error.
But I waited a bit longer, to see if anyone found a usage case and could
make it work.
Noone has. The people who said pledge is wrong because it can't be maintained
over execve are wrong -- rather than understanding the workings of Unix they
are only thinking of their impossible desires.
