From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.web.de (mout.web.de [212.227.15.4]) by sourceware.org (Postfix) with ESMTPS id 74681386EC55 for ; Sun, 17 Jan 2021 11:28:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 74681386EC55 X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from localhost ([213.55.224.202]) by smtp.web.de (mrweb002 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MeSYJ-1lP3fP1muN-00QDu2 for ; Sun, 17 Jan 2021 12:28:04 +0100 Date: Sun, 17 Jan 2021 12:28:03 +0100 From: Andreas Fink To: libc-help@sourceware.org Subject: Re: Hooking execve for an LD_PRELOAD library In-Reply-To: <878s8srmnh.fsf@oldenburg.str.redhat.com> References: <1MiMEW-1lf4081KQ2-00fS4y@smtp.web.de> <878s8srmnh.fsf@oldenburg.str.redhat.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Message-ID: <0LgHf2-1lmY0O29NE-00ngvl@smtp.web.de> X-Provags-ID: V03:K1:BfCUWiKOmAmU8MLNhkg1m8101GmMovhgSTWOZeGaZDI9mBz9U53 /rntfMCDdQeqrlnLNO4eJb1qYfCySOJrJEm8YoFAq1Y70OBgxJH1N+20GoeiJFE01Occ7nD vT3THl5E8oizp5LQ00vPq+Hwqkq+sb9F/H4BX1vh5IBTJGCgy+C2qeD6GsXX6smg6twe0xL N4b04nybioIgXp8GlRRjQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:uGZFD8djCTM=:vzXP1ewPVSwuKHIODAcziz tkLt25KIUe6Jt+fvHwPzPpPRQDxQVDlACSEYme5TwH25UT4CAHrotWIJwyNuMyaCXib9YUmZB NdkM5TEHMN4Hzb8Kcb9rVwFbTSOf8cJBkGgpw/uZgpXejPZkd6ki8KQDfnlgfRbatakH2akJT 28K2keajErzznsFVwbYUDcxkneejYdapvfbfjZ/RyPzr8FFDIDxAor0aAiF0R71EdF6biA1rA ec87Dhup0ot0/PVFJVebfSWFpqP7Vb6joDNpSIoH6eIgW2FBej/Skw/R9cd69dxTRNw8F8l/K 3FYcD9/HOX+LDxPdzUh2qpE5DRd8vG7vWzkpKdOLv84hmxfWa0GDTzly6bE6+9lB/DowwsQBL 4ToNd+9L0uJZvY0nJKOHOcGGFzCFnWCAP/tS9CT5j86wDHFHDbWyCaIkRg1XR7zfFix7VVrHd sW2ULAzNgIV354LE4cCHWxR3919jnF6saLyXPmrW47XA0ewVeaBlT0IxxEcSLMqkcaW8VXaji Q0t561yYQ+xbAo59jqxeFFvGnFGw66CiDf2x+Q6feqKmjTnKKpt0IjZzzf/J0D3cPjDM/GXQ2 cGL1+8ELkrjuWc/6NSAWFSuOKdqcAATSDb2g3DV0eyKBGu256kt6I+aZflKsWhQ3qZCUl6acS db4BYrDrp6OHeq9oBSUrDyF8/ogoAWRLveh8lWSUrLZx8TEzsmOGB+HvvdyAV8RpSVTETVCuo 3G7io9vMsePaKdVE9nI/0L/JeltP5bXLPfyHdOvSGT5uiC1jLe2S08djLHZGgM5LHMRYIN5Er jLYNDJEP4sWi9qrKsAG0DWag8X+I+d5L8dtEqVMkb0UMhUWvRwe3YZOGmhwpGN+Aj5i/wGIMi SoJPk/mNJWyQ+3WJcl3A== X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 11:28:08 -0000 On Sun, 17 Jan 2021 09:30:10 +0100 Florian Weimer wrote: > * Andreas Fink via Libc-help: > > > Now I would like the same for execvp to happen. Reading the man page o= f > > execvp it is mentioned that exec-family functions are just > > frontends to execve, so I replaced in my executable source code the > > explicit call to execve with a call to execvp. I expected that this > > would just work, as execvp would in turn call execve and this would be > > caught by the hook, then logged and forwarded to the real > > implementation. But to my surprise no such thing happened. execvp woul= d > > run successfully, but my hook would never be called. > > Why is the hook not called, what did I miss? > > Most internal function calls are implemented as direct function call, > and it is not possible to use symbol interposition to redirect them. > An exception is the malloc family of functions: > > Replacing malloc > > > If you want to modify the behavior of execve, you should consider a > kernel-based mechanism. This will likely make it easier to achieve > correct behavior after vfork, too. > > Thanks, > Florian Ok, if I understood you correctly this is the expected behaviour. I was afraid of it, but ok I can live with it. Assuming I want to hook the whole exec-family, it seems easy to just add hooks for the execv* functions while forwarding all arguments to the corresponding glibc implementation. Forwarding the execl* functions seems a bit more involved, as I would have to bend the va_list to an array, or is there some way to forward the arguments to the glibc function without unwrapping the va_list? Kernel-based mechanism (in my case that's Linux) sounds also interesting as it is one level lower I guess, but honestly speaking I have no idea where to start to look at. Do you know of an example (not necesserily execve, but any system call where this is done)? I guess glibc must do this of course, but I could not directly find for example the real implementation of execve. Only the stub one in posix/execve.c, but this is certainly not the real implementation, as it returns always an error ;) I think for my real use case I can get away with hooking all functions on top of glibc, still interested to learn new things. Best Andreas