[Buildroot] [PATCH 0/2] core/sdk: fix relative symlinks in generated tarball (branch yem/sdk)

Joel Carlson JoelsonCarl at gmail.com
Sat Dec 22 18:21:39 UTC 2018


On Sat, Dec 22, 2018 at 1:31 AM Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
>
> Joel, Andreas, All,
>
> On 2018-12-21 17:13 -0700, Joel Carlson spake thusly:
> > On Fri, Dec 21, 2018 at 2:46 AM Andreas Naumann <dev at andin.de> wrote:
> > > However, the check for symlinks pointing out of host/ showed to two
> > > issues originating in install steps of iptables and eudev. Both create
> > > links that point to system pathes.
> > >
> > > I have locally made POST_STAGING_HOOKS to fix that but that's probably a
> > > non acceptable hack.
> >
> > Would be hard to tell without seeing the actual change. ;-)
> > That being said, this is probably something that would need to be
> > fixed in iptables and eudev (patches submitted upstream), and then
> > those patches added to buildroot to fix the issue.
> >
> > So far I've submitted a patch to iptables here:
> > http://patchwork.ozlabs.org/patch/1017739/
> >
> > And a patch to buildroot to pull in a version of that here:
> > https://patchwork.ozlabs.org/patch/1017740/
> >
> > I've also submitted a pull request for eudev (and while typing this
> > email it was already merged):
> > https://github.com/gentoo/eudev/pull/165
>
> I did nt see Thomas' reply to the iptables patch before I replied to
> your eudev one. It turns out we basically said exactly the same thing:
> this is not the correct solution.

My apologies on submitting a bad patch.

> If you do what you propose, then you can see that at runtime, on the
> _target_, the symlinks will be wrong, bnecause they would be prefixed
> with the DESTDIR, which is clearly not appropriate.
>
> A better solution, in that case, wuld be to make relative symlinks
> instead, but that is a little bit trickier.  A simple way to do that is
> to use 'ln -r -s FILE LINK' but the -r option is not old enough to be
> widely available on all distors, especially entreprise-grade distros.
>
> An other approach, would be that we whietelist certain PATHs from our
> SDK. Afterall, there are things we do not care about in the SDK. For
> example, most executables in staging/{,usr/}{,s}bin are not needed. We
> only really need libs and headers, so we could just ignore anything
> that is not in staging/{lib,usr/lib,usr/include}/
>
> I.e. the heuristic would become:
>
>   if it is a symlink:
>       if is not below staging/:
>           check and fix it
>       else if it is below staging/{lib,usr/lib,usr/include}:
>           check and fix it
>       else
>           ignore it
>
> I can try to look into fixing that in my series. Is enabling eudev
> and/or iptables enough to echibit the problem?

That is a better solution. And yes, with the previous sdk fixes
applied, just enabling eudev and/or iptables and then trying to 'make
sdk' would error out because of the symlink path being outside of
staging.
> Regards,
> Yann E. MORIN.
>
> > I'll submit a patch for eudev in buildroot to pull in that change once
> > I see feedback on the iptables one. For it to work for me I needed to
> > set AUTORECONF=YES on eudev, but I don't really understand
> > autotools/automake stuff very well and I don't know if that is the
> > right way to be doing things.
> > -Joel
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'


More information about the buildroot mailing list