Remove broken symlinks from /usr/bin

[sdavids]

$ docker run --rm -it asciidoctor/docker-asciidoctor:1.89 find /usr/bin -xtype l -exec test ! -e {} \; -print
/usr/bin/jar
/usr/bin/autoinst
/usr/bin/javac
/usr/bin/convertgls2bib
/usr/bin/lily-image-commands
/usr/bin/pmxchords
/usr/bin/vpl2ovp
/usr/bin/jinfo
/usr/bin/eolang
/usr/bin/bib2gls
/usr/bin/diadia
/usr/bin/urlbst
/usr/bin/musixflx
/usr/bin/mf2pt1
/usr/bin/jmod
/usr/bin/jshell
/usr/bin/jexec
/usr/bin/jstack
/usr/bin/httexi
/usr/bin/javadoc
/usr/bin/serialver
/usr/bin/jexec-binfmt
/usr/bin/ht
/usr/bin/jdeps
/usr/bin/ltx2unitxt
/usr/bin/afm2afm
/usr/bin/checkcites
/usr/bin/httex
/usr/bin/jstat
/usr/bin/mkt1font
/usr/bin/bibzbladd
/usr/bin/biburl2doi
/usr/bin/rmid
/usr/bin/m-tx
/usr/bin/jhsdb
/usr/bin/vpl2vpl
/usr/bin/ltx2crossrefxml
/usr/bin/lily-glyph-commands
/usr/bin/jarsigner
/usr/bin/bibmradd
/usr/bin/listbib
/usr/bin/jjs
/usr/bin/musixtex
/usr/bin/unpack200
/usr/bin/pack200
/usr/bin/jstatd
/usr/bin/ulqda
/usr/bin/mk4ht
/usr/bin/htlatex
/usr/bin/bbl2bib
/usr/bin/bibexport
/usr/bin/fontinst
/usr/bin/jps
/usr/bin/bibdoiadd
/usr/bin/albatross
/usr/bin/jdb
/usr/bin/jdeprscan
/usr/bin/rubikrotation
/usr/bin/jlink
/usr/bin/ot2kpx
/usr/bin/javap
/usr/bin/jimage
/usr/bin/bibcop
/usr/bin/lily-rebuild-pdfs
/usr/bin/jaotc
/usr/bin/texfindpkg
/usr/bin/multibibliography
/usr/bin/htmex
/usr/bin/xhlatex
/usr/bin/pedigree
/usr/bin/jcmd
/usr/bin/rmic
/usr/bin/jmap

In addition, I am not sure if all binaries are necessary here:

$ ls /usr/lib/jvm/default-jvm/bin
java         jfr          jrunscript   keytool      rmiregistry

[dduportal]

🤔 I would like to understand why are these symlinks created in first place. Is this an Alpine Linux package removal which does not purge them?

[sdavids]

I investigated a little with dive:

docker-asciidoctor/Dockerfile

Lines 62 to 92 in 8b9e96b

	RUN apk add --no-cache \
	bash \
	curl \
	ca-certificates \
	findutils \
	font-bakoma-ttf \
	git \
	gnuplot \
	graphviz \
	inotify-tools \
	make \
	openjdk21-jre \
	python3 \
	py3-cairo \
	py3-setuptools \
	ruby-bigdecimal \
	ruby-nokogiri \
	# Required for asciidoctor-epub
	ruby-ffi \
	ruby-mathematical \
	ruby-rake \
	texlive \
	texmf-dist-latexextra \
	ttf-liberation \
	ttf-dejavu \
	tzdata \
	unzip \
	which \
	font-noto-cjk \
	&& apk add --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/testing \
	pdf2svg

The command above creates the symlinks.

$ docker run --rm -it alpine:3.22.0 sh -c 'ls /usr/bin/jshell ; apk add -q --no-progress openjdk21-jre ; ls -l /usr/bin/jshell ; ls /usr/lib/jvm/default-jvm/bin'
ls: /usr/bin/jshell: No such file or directory
lrwxrwxrwx    1 root     root            33 Jun 30 16:17 /usr/bin/jshell -> ../lib/jvm/default-jvm/bin/jshell
java         jfr          jrunscript   jwebserver   keytool      rmiregistry

Seems an issue with the package but all those broken symlinks do not come only from the openjdk21-jre package:

$ docker run --rm -it alpine:3.22.0 sh -c 'apk add -q --no-progress openjdk21-jre ; find -L /usr/bin -type l -print'
/usr/bin/jar
/usr/bin/javac
/usr/bin/jinfo
/usr/bin/jmod
/usr/bin/jshell
/usr/bin/jexec
/usr/bin/jstack
/usr/bin/javadoc
/usr/bin/serialver
/usr/bin/jexec-binfmt
/usr/bin/jdeps
/usr/bin/jstat
/usr/bin/rmid
/usr/bin/jhsdb
/usr/bin/jarsigner
/usr/bin/jjs
/usr/bin/unpack200
/usr/bin/pack200
/usr/bin/jstatd
/usr/bin/jps
/usr/bin/jdb
/usr/bin/jdeprscan
/usr/bin/jlink
/usr/bin/javap
/usr/bin/jimage
/usr/bin/jaotc
/usr/bin/jcmd
/usr/bin/rmic
/usr/bin/jmap

[sdavids]

I have opened https://gitlab.alpinelinux.org/alpine/aports/-/issues/17318 upstream but I think this PR should be merged regardless.

[dduportal]

I have opened https://gitlab.alpinelinux.org/alpine/aports/-/issues/17318 upstream but I think this PR should be merged regardless.

I don't think we should rush to merge this PR unless you have a real problem caused by these (broken) symlinks that would require an urgent change.

Is there a blocker for you?

[sdavids]

Having un-targeted symlinks lying around is a CVE waiting to happen …

They are easily accessible on top:

$ docker run --rm -it asciidoctorw/docker-asciidoctor:1.89 jshell

💥

[bratkartoffel]

Having un-targeted symlinks lying around is a CVE waiting to happen …

They are easily accessible on top:

$ docker run --rm -it asciidoctorw/docker-asciidoctor:1.89 jshell

💥

I'm the maintainer of the openjdk9+ aports on alpine.

Could you please explain how this can cause a CVE? Yes, the symlinks are dangling but they point to well known locations (/usr/lib/jvm/...) where only root may write to. If someone has write access to this location you have way more problems than symlinks.

The symlinks are created by the java-common aport, which has been created quite some time ago. I just created links for all the binaries in java 9. This way, no matter which kind of jre / jdk you install, all the binaries are available in $PATH. I've never thought about dangling symlinks being a real problem.

[dduportal]

Having un-targeted symlinks lying around is a CVE waiting to happen …

They are easily accessible on top:

$ docker run --rm -it asciidoctorw/docker-asciidoctor:1.89 jshell

💥

Thanks for the clarification. However I don't see this example as serious enough: even with the symlinks removed, someone can still cyber-squat a user namespace such as asciidoctorw and replace the existing binaries.

=> As much as you are correct to report this and to forward to upstream, I don't think we should rush such a change

[dduportal]

Having un-targeted symlinks lying around is a CVE waiting to happen …
They are easily accessible on top:
$ docker run --rm -it asciidoctorw/docker-asciidoctor:1.89 jshell
💥

I'm the maintainer of the openjdk9+ aports on alpine.

Could you please explain how this can cause a CVE? Yes, the symlinks are dangling but they point to well known locations (/usr/lib/jvm/...) where only root may write to. If someone has write access to this location you have way more problems than symlinks.

The symlinks are created by the java-common aport, which has been created quite some time ago. I just created links for all the binaries in java 9. This way, no matter which kind of jre / jdk you install, all the binaries are available in $PATH. I've never thought about dangling symlinks being a real problem.

Thanks @bratkartoffel ! As I understand the comment https://gitlab.alpinelinux.org/alpine/aports/-/issues/17318#note_521090, it means we should keep the issue here opened until the Alpine package is corrected (or not but with consensus on why keeping the symlinks): am I understanding it correctly?

[sdavids]

I have opened another issue upstream.

[sdavids]

they point to well known locations (/usr/lib/jvm/...) where only root may write to. If someone has write access to this location you have way more problems than symlinks.

This is correct.

The current setup is as follows:

$ docker run --rm -it alpine:3.22.0 sh -c 'apk add -q --no-progress openjdk21-jre ; ls -la /usr/bin/jshell ; echo ; ls -la /usr/lib/jvm/default-jvm'
lrwxrwxrwx    1 root     root            33 Jul  1 12:06 /usr/bin/jshell -> ../lib/jvm/default-jvm/bin/jshell

lrwxrwxrwx    1 root     root            15 Jul  1 12:06 /usr/lib/jvm/default-jvm -> java-21-openjdk

One would either have to place something at /usr/lib/jvm/java-21-openjdk/bin/jshell or place something somewhere and change the /usr/lib/jvm/default-jvm -> java-21-openjdk symlink.

---

The dangling symlinks from the texlive package point to /usr/share/texmf-dist/scripts/pedigree-perl/pedigree.pl for example.

---

The main danger is that /usr/bin is in $PATH.

A specifically crafted apk package/Docker layer: "Look Ma, nothing happened in /usr/bin — nothing dirty has been added to our $PATH".