Symlinks to libc are followed by the dump and copy plugins

Bug #1658774 reported by Kyle Fazzari
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snapcraft
Fix Released
Medium
Kyle Fazzari

Bug Description

Snapcraft has some special-case code where, if a stage-package is pulled with symlinks to libraries contained within libc, snapcraft allows them to dangle knowing that they'll be pointing to (hopefully) valid locations once run. However, the various plugins in snapcraft also have code that checks for dangling symlinks, and rewrites (or follows) them as necessary to make sure the snap won't be broken once run. This is conflicting logic, and it particularly comes to light when using content sharing. When trying to build a content consumer by tarring the producer's staging area and adding it as a part to the consumer, the plugins follow the symlinks that are dangling in the producer, copying libc in from the system. Which means if any other part in the consumer stages something that has symlinks to libc again (which are left dangling), they conflict with the parts that were already staged.

To overcome this whole issue, ideally snapcraft could simply _remove_ symlinks to libc. However, as discussed in the comments below this doesn't work in practice. Therefore, the plugins that rewrite/follow symlinks need to be updated to allow libc symlinks to pass through.

Revision history for this message
Kyle Fazzari (kyrofa) wrote :
Changed in snapcraft:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Kyle Fazzari (kyrofa)
importance: High → Medium
Changed in snapcraft:
status: In Progress → Fix Committed
milestone: none → 2.27
Changed in snapcraft:
status: Fix Committed → Fix Released
Revision history for this message
Sergio Schvezov (sergiusens) wrote :

This caused LP: #1665089

Please add a pkg-config/libtool test when working on this again.

Changed in snapcraft:
milestone: 2.27 → none
status: Fix Released → Triaged
Revision history for this message
Kyle Fazzari (kyrofa) wrote :

Definitely, thank you.

Revision history for this message
Kyle Fazzari (kyrofa) wrote :

The solution suggested in the PR (to remove the symlinks to libc) doesn't quite work the way we'd hoped. The cause of the issue at least mostly seems to be libc6-dev, which contains a /usr/lib/x86_64-linux-gnu/libdl.so symlink that points to /lib/x86_64-linux-gnu/libdl.so.2 (which is contained within libc). libc6-dev also contains /usr/lib/x86_64-linux-gnu/libdl.a, which is not a symlink, and of course does not get removed. Due to how ld works, and since the part's search paths are higher-priority than the host's search paths, ld selects libdl.a instead of the .so on the host, which causes build errors. Removing libdl.a from the part causes both network-manager and my minimal reproducer to build successfully, as ld eventually finds libdl.so on the host.

In conclusion, it seems the only solution to this problem is to go the other direction with it: modify the rest of Snapcraft not to follow symlinks to libc.

Kyle Fazzari (kyrofa)
summary: - Symlinks to libc left dangling
+ Symlinks to libc are followed by the dump and copy plugins
description: updated
Revision history for this message
Kyle Fazzari (kyrofa) wrote :
Changed in snapcraft:
status: Triaged → In Progress
Changed in snapcraft:
status: In Progress → Fix Committed
milestone: none → 2.28
Changed in snapcraft:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.