There seems to be a lot of pledge calls in your program. A quick glance through the source tree and the only program I could find with more is smtpd. I also didn't see anywhere you were calling pledge with a non null execpromises.

You could also try adding the `error' promise so that it won't sigabort and maybe you can find where the problem is easier.


Edgar

On 11/25/21 4:55 AM, Luke Small wrote:
I ran ktrace. Kdump said the last thing it did was try to load
/usr/libexec/ld.so

To main(), before the unveil pledge is dropped, I added:

         if (unveil("/usr/libexec/", "rx") == -1)
                 err(1, "unveil, line: % d", __LINE__);

After running it again, it spits out an error message:

ld.so: pkg_ping: can't load library 'libc.so.96.1'

So I put in:

         if (unveil("usr/lib/", "rx") == -1)
                 err(1, "unveil, line: %d", __LINE__);

Now it successfully execv()s into the new process space!
Now in the newly created program, which hasn’t set new pledge execpromises,
it won’t successfully run ftp(1) because it wasn’t granted the inet
execpromise.

execpromises seems to have carried over!

On Thu, Nov 25, 2021 at 2:24 AM Sebastien Marie <sema...@online.fr> wrote:

On Thu, Nov 25, 2021 at 01:52:31AM -0600, Luke Small wrote:
The attachment is a version of the c file at:
https://github.com/lukensmall/pkg_ping
the version is the repository doesn't have your changes. Thanks for
the attached version.

After it does a fork-exec to ftp(1) to pipe in ftplist from a random
hard-coded mirror, I short circuit it (for debugging) at the line that
says:
“if (n || array_length == 0 || loop == 20)”
by putting in “loop == 20” which is the default loop value, where it is
decremented in further iterations of calling pkg_ping in the restart
function which only occurs in rare download errors. If it succeeds with
the
execv in the restart function, it should work normally.
Just to be clear: I will not run random code (as normal user or as root).

Could you run (as user):

$ ktrace -di ./pkg_ping whatever-to-reproduce-the-problem

and share the output of `kdump` ?

Beware that the file might be large (so gzip it) and could contains
sensitive information (so better to review it).

Seeing a gdb backtrace might be useful too.

Thanks.
--
Sebastien Marie


Reply via email to