installing snap with layout on /etc/ld.so.cache results in deleted mount
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
After installing a snap that modifies the file $SNAP_DATA/
```
$ snap install update-
$ snap connect update-
$ sudo snap run --shell update-ldconfig -c "cat /proc/self/
$ sudo update-ldconfig
+ '[' '!' -f /var/snap/
+ mkdir -p /var/snap/
+ cp -r /etc/ld.
+ cp -r /etc/ld.so.conf /var/snap/
++ echo /var/lib/
++ sed -e s/:://
+ LD_LIBRARY_
+ IFS=:
+ read -ra PATHS
+ ldconfig -C /var/snap/
$ sudo snap run --shell update-ldconfig -c "cat /proc/self/
4696 4851 259:6 /var/snap/
```
This is the snap.yaml:
```
name: update-ldconfig
version: '0.1'
summary: update-ldconfig
description: update-ldconfig
apps:
update-ldconfig:
command: update-ldconfig.sh
command-chain:
- snap/command-
plugs:
- mount-observe
architectures:
- amd64
base: core18
confinement: strict
grade: devel
layout:
/etc/ld.so.cache:
bind-file: $SNAP_DATA/
```
with update-ldconfig.sh defined as :
```
#!/bin/bash -ex
# make sure our fake ld.so.cache exists
if [ ! -f "$SNAP_
echo "snap private ld.so.cache doesn't exist!"
exit 1
fi
# copying the conf dir from real /etc into $SNAP_DATA
mkdir -p "$SNAP_
cp -r /etc/ld.so.conf.d/* "$SNAP_
cp -r /etc/ld.so.conf "$SNAP_
# delete empty entries in the LD_LIBRARY_PATH
# i.e. change "/a/b/c:
LD_LIBRARY_
# run ldconfig on our LD_LIBRARY_PATH lib dirs
IFS=':' read -ra PATHS <<< "$LD_LIBRARY_PATH"
ldconfig -C "$SNAP_
```
I tried this both on stable and with master build of snapd. I can't seem to reproduce this with other paths so if I had to guess this has something to do with /etc/ld.so.conf already existing.
Zygmunt any idea if this fixed by the MS_SHARED patch you have (or one of the other PR's you have in flight for mount namespace bugs)?
Changed in snapd: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
This is not going to be fixed by MS_SHARED
I think the following happens:
touch source target
mount --bind source target
rm source
# now target is a deleted mount
This is what ldconfig does, it seems to rewrite the file by unlinking the original at some point. I didn't test this theory but it is the mechanism in which deleted mounts can be created.
As a workaround I would suggest to use a symlink: /etc/ld.so.cache -> $SNAP_DATA/ ld.so.cache and then run ldconfig on the $SNAP_DATA location.