On Thu, Nov 25, 2021 at 5:17 AM Claudio Jeker
wrote:
> On Thu, Nov 25, 2021 at 04:55:23AM -0600, 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(
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
On Thu, Nov 25, 2021 at 04:55:23AM -0600, 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, lin
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
Sebastien Marie wrote:
> If the code you are using is restricted and can't be showed, please at
> least show a ktrace output of the program run. At this point I am
> still unsure that it is execve(2) which is causing pledge violation.
actually I want to know where garbage code like this runs to
On Wed, Nov 24, 2021 at 10:55:56PM -0600, Luke Small wrote:
> I took a hard look at it again…with more printf()s.
>
> It is killed at the execv which calls the calling executable to get
> different random number generated values with a slightly different argv set
> to prevent an indefinite loop.
>
I took a hard look at it again…with more printf()s.
It is killed at the execv which calls the calling executable to get
different random number generated values with a slightly different argv set
to prevent an indefinite loop.
I put the following in before the execv:
int i = pledge("stdio exec r
It kills your secret program because it is broken.
>From the manual page:
A process which attempts a restricted operation is killed with an
uncatchable SIGABRT, delivering a core file if possible.
You are so incapable of reading and learning.
I am asking you to leave this list.
Luk
It works great, up until the time that pledge() ITSELF gets shot in the
head, which seems would be impossible! It’s supposed to only throw errors!
Or did I miss the memo that there’s a “pledge” pledge?
On Wed, Nov 24, 2021 at 8:19 PM Theo de Raadt wrote:
> You have a secret program and you want
You have a secret program and you want people on the internet to help
you debug what you have done wrong in this secret program.
You obviously don't know what you are doing, and I think you don't
deserve help.
Luke Small wrote:
> I have a program which runs fork() a couple times with pledges:
I have a program which runs fork() a couple times with pledges: “stdio
cpath wpath” for writing to disk and “stdio dns” for a dns caching process
after accepting command-line input. Is the execpromises, permitted to
increase/change to accommodate the different fork()s from the parent? If
so, why is
On 11/24/21 11:50 AM, Luke Small wrote:
I tried calling pledge with a non-NULL execpromise and noticed that it was
killed. That’d be convenient if that behavior was noted in the man page!--
-Luke
You want to look at the "exec" portion of the manual. execpromises are
for setting up pledge fo
I tried calling pledge with a non-NULL execpromise and noticed that it was
killed. That’d be convenient if that behavior was noted in the man page!--
-Luke
13 matches
Mail list logo
