<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 14, 2022 at 3:23 PM Eugene Syromyatnikov <<a href="mailto:evgsyr@gmail.com">evgsyr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 14, 2022 at 10:37 PM Dan Stromberg <<a href="mailto:drsalists@gmail.com" target="_blank">drsalists@gmail.com</a>> wrote:<br>
> So anyway, I'm strace'ing a #!/usr/bin/python2 script.<br>
><br>
> I expected to see an exec of /usr/bin/python2, but I don't.  I just see an<br>
> exec of /tmp/t.<br>
<br>
Why, exactly, did you expect that? strace doesn't parse binary<br>
supplied as a command (or runs a shell to do so), it just executes it<br>
(as stated in the NOTES section in the man page[0]). The parsing of<br>
the interpreter is performed in-kernel by the binfmt_script loader[1]<br>
(along with all its limitations like interpreter command line size and<br>
single argument only).<br></blockquote><div><br></div><div>I thought I had seen a second exec for a #! script, but perhaps I was misremembering.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Was this some sort of security feature I never heard about?  I'm tracing a<br>
> very simple time.sleep(10) here, but the same thing is (not) happening in a<br>
> larger script that I need to track down a bug in.<br>
<br>
Is that script run in a shell? That would explain it.<br></blockquote><div>The larger script is clone'd and execve'd by a C++ program.</div><div><br></div><div>It's possible I collected the strace outputs too soon, but I see another Python program logging messages that don't show up in the strace.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Is there a way I can coax Linux and/or strace to show all the exec's, like<br>
> they used to?<br>
<br>
All executed execve() calls are shown.<br></blockquote><div>That's good to hear.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> what else is missing from the strace report.<br>
<br>
syscalls performed by the child process before the first<br>
execv/execve/execveat call are not shown, but they usually not<br>
pertaining to the trace, see TCB_HIDE_LOG/hide_log() usage[2][3].<br>
<br>
[0] <a href="https://gitlab.com/strace/strace/-/blob/v5.10/strace.1.in#L1641" rel="noreferrer" target="_blank">https://gitlab.com/strace/strace/-/blob/v5.10/strace.1.in#L1641</a><br>
[1] <a href="https://elixir.bootlin.com/linux/v5.16/source/fs/binfmt_script.c#L34" rel="noreferrer" target="_blank">https://elixir.bootlin.com/linux/v5.16/source/fs/binfmt_script.c#L34</a><br>
[2] <a href="https://gitlab.com/strace/strace/-/blob/v5.16/src/strace.c#L3116" rel="noreferrer" target="_blank">https://gitlab.com/strace/strace/-/blob/v5.16/src/strace.c#L3116</a><br>
[3] <a href="https://gitlab.com/strace/strace/-/blob/v5.16/src/syscall.c#L634" rel="noreferrer" target="_blank">https://gitlab.com/strace/strace/-/blob/v5.16/src/syscall.c#L634</a><br></blockquote><div>OK.  Thanks!<br> <br></div></div></div>