[OE-core] pseudo: host user contamination

[Andre McCurdy]

On Fri, Mar 23, 2018 at 4:56 PM, Seebs <seebs at seebs.net> wrote:
> On Fri, 23 Mar 2018 23:47:30 +0000
> Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
>> On Fri, 2018-03-23 at 11:49 -0500, Seebs wrote:
>> > On Fri, 23 Mar 2018 16:30:55 +0000
>> > "Burton, Ross" <ross.burton at intel.com> wrote:
>> > > Because in GNU's infinite wisdom they're using renameat2() to do
>> > > atomic renames in the mv command, and as renameat2 isn't in the
>> > > headers for F27 it just does a syscall directly. This is in
>> > > upstream
>> > > coreutils so once they make a release, everyone gets it.
>> > UGH.
>> >
>> > I... am really unsure whether it's possible to catch that, because
>> > I really, really, don't want to try to intercept raw syscall()
>> > calls. I don't think that ends well.
>>
>> Just out of interest for my education, why is that a really bad idea?
>> Loops, e.g. with memory allocation issues?
>
> Potentially. We rely pretty heavily on the assumption that an *actual*
> syscall can go through.
>
> Although... Actually, I don't even know if this is an actual syscall.
> This could be an actual glibc wrapper around the syscall interface,
> just like all the others, which is not the *actual* raw syscall or
> whatever,

It looks like coreutils calls into gnulib, which calls the libc's
syscall wrapper:

  http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/renameat2.c;h=a295ec33f33dfe14e1d29cfae5d2c36e82d01ef4;hb=HEAD#l74

Interposing the libc syscall wrapper doesn't seem to scary if you can
transparently pass on everything apart from syscall(SYS_renameat2,
...) ?

> and... I have no idea how often that is or isn't hit.
>
> It's totally possible it would work, but basically, I have a pretty
> good intuition of when something sounds brittle and error-prone, and
> trying to trap syscall() sounds brittle and error-prone and might work
> today but not next week...