[OE-core] pseudo: host user contamination

[Andre McCurdy]

On Mon, Mar 26, 2018 at 12:31 PM, Seebs <seebs at seebs.net> wrote:
> On Mon, 26 Mar 2018 20:49:30 +0200
> Andreas Müller <schnitzeltony at gmail.com> wrote:
>
>> Interesting background: mv/renameat2 change seemed so important for
>> Fedora that they backported the changes into 8.27.
>
> It looks like the reason for this is the RENAME_NOREPLACE flag, which
> avoids a possible race condition.
>
> FWIW, I've traded a couple of emails with the coreutils people, and I
> think at this point I'm going to try a custom wrapper for syscall that
> just yields ENOTSUPP, because any attempt to do something fancier
> seems like it's going to be potentially error-prone.
>
> Since the man page gave the ia64 example, I went and checked, and it
> is indeed the case that calls other than syscall(2) will clobber r10
> after system calls, so it's actually not possible for a C wrapper to
> do what we want on an intercepted syscall.

That's based on your assumption that a C wrapper needs to care about
results in architecture specific registers, which I contend is not a
correct interpretation of the syscall manpage.

Did you find any evidence to support your interpretation? e.g. Did you
find any examples of callers to the libc syscall() API which use
architecture specific assembler to examine the result of the syscall?

The gnulib code calling syscall(SYS_renameat2, ...) certainly doesn't
do that - it just checks the C function return value and errno. Since
there's no architecture specific code to examine the syscall() result,
do you expect coreutils mv to now incorrectly detect errors on ia64?