[musl] Bug: installed symlinks are unreadable on MacOS

[musl] Bug: installed symlinks are unreadable on MacOS

[Tim Cuthbertson]

[-- Attachment #1.1: Type: text/plain, Size: 1375 bytes --]

I'm not subscribed to the mailing list, please CC me on replies.

Installed symlinks (specifically ld-musl-x86_64.so.1 have permissions 0700
on MacOS, which means only the owner (typically root) can read them.

Symlink permissions can't be anything but 0777 on Linux, but on Mac they
can be set, and in this case are being inherited from the 077 umask in
install.sh:

```
$ ls -l
/nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1
ls: cannot read symbolic link
'/nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1':
Permission denied
lrwx------ 1 root wheel 7 Jan  1  1970
/nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1
```

My fix (attached) is to use `umask 022`, which was already being used to
make directories. It's not practical to fix this by specifying the intended
permissions for this symlink, as setting link permissions requires the
nonstandard `-h` chmod flag, which presumably fails on other platforms.

First discovered when cross-building on MacOS for linux:
https://github.com/NixOS/nixpkgs/issues/285141

I've tested the fix works in nix. I am fairly confident the same issue
exists outside of Nix given the fix, but I haven't built musl before and
ran into unrelated errors.

Thanks,
 - Tim

[-- Attachment #1.2: Type: text/html, Size: 1708 bytes --]

[-- Attachment #2: musl-chmod.patch --]
[-- Type: application/octet-stream, Size: 741 bytes --]

From 05b89f783fd1873ce9ec1127fa76d002921caa23 Mon Sep 17 00:00:00 2001
From: Tim Cuthbertson <tim@gfxmonk.net>
Date: Wed, 31 Jan 2024 12:45:06 +1100
Subject: [PATCH] install.sh: relax umask to fix restrictive symlink
 permissions on MacOS

---
 tools/install.sh | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/install.sh b/tools/install.sh
index d913b60bf..62ca4011c 100755
--- a/tools/install.sh
+++ b/tools/install.sh
@@ -36,8 +36,9 @@ esac
 set -C
 set -e
 
-if test "$mkdirp" ; then
 umask 022
+
+if test "$mkdirp" ; then
 case "$2" in
 */*) mkdir -p "${dst%/*}" ;;
 esac
@@ -45,8 +46,6 @@ fi
 
 trap 'rm -f "$tmp"' EXIT INT QUIT TERM HUP
 
-umask 077
-
 if test "$symlink" ; then
 ln -s "$1" "$tmp"
 else

Re: [musl] Bug: installed symlinks are unreadable on MacOS

[Rich Felker]

On Wed, Jan 31, 2024 at 01:30:21PM +1100, Tim Cuthbertson wrote:
> I'm not subscribed to the mailing list, please CC me on replies.
> 
> Installed symlinks (specifically ld-musl-x86_64.so.1 have permissions 0700
> on MacOS, which means only the owner (typically root) can read them.
> 
> Symlink permissions can't be anything but 0777 on Linux, but on Mac they
> can be set, and in this case are being inherited from the 077 umask in
> install.sh:
> 
> ```
> $ ls -l
> /nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1
> ls: cannot read symbolic link
> '/nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1':
> Permission denied
> lrwx------ 1 root wheel 7 Jan  1  1970
> /nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1
> ```
> 
> My fix (attached) is to use `umask 022`, which was already being used to
> make directories. It's not practical to fix this by specifying the intended
> permissions for this symlink, as setting link permissions requires the
> nonstandard `-h` chmod flag, which presumably fails on other platforms.
> 
> First discovered when cross-building on MacOS for linux:
> https://github.com/NixOS/nixpkgs/issues/285141
> 
> I've tested the fix works in nix. I am fairly confident the same issue
> exists outside of Nix given the fix, but I haven't built musl before and
> ran into unrelated errors.
> 
> Thanks,
>  - Tim

Thanks for catching this. Do you think it might be better to put umask
000 inside the symlink case instead of just reusing the 022 from dir?
000 seems like what you actually want to fix the symlink behavior.

Alternatively maybe we should set umask to the complement of the
desired mode?

Rich

Re: [musl] Bug: installed symlinks are unreadable on MacOS

[Tim Cuthbertson]

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]

Yeah, setting it to `chmod 000` in just the symlink branch seems good to me
too.

Looking at the script more closely, `mode` is always set and so I'm unclear
why there is also a `umask 077` at all. Whatever permissions we create the
file with, we `chmod` it explicitly before doing anything else.

Is that line just there to undo the potential change to `umask` in the
mkdirp branch? If so, maybe that should be done explicitly by capturing the
old umask? e.g:

if test "$mkdirp" ; then
umaskorig="$(umask)"
umask 022
case "$2" in
*/*) mkdir -p "${dst%/*}" ;;
esac
umask "$umaskorig"
fi


On Thu, 1 Feb 2024 at 00:47, Rich Felker <dalias@libc.org> wrote:

> On Wed, Jan 31, 2024 at 01:30:21PM +1100, Tim Cuthbertson wrote:
> > I'm not subscribed to the mailing list, please CC me on replies.
> >
> > Installed symlinks (specifically ld-musl-x86_64.so.1 have permissions
> 0700
> > on MacOS, which means only the owner (typically root) can read them.
> >
> > Symlink permissions can't be anything but 0777 on Linux, but on Mac they
> > can be set, and in this case are being inherited from the 077 umask in
> > install.sh:
> >
> > ```
> > $ ls -l
> >
> /nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1
> > ls: cannot read symbolic link
> >
> '/nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1':
> > Permission denied
> > lrwx------ 1 root wheel 7 Jan  1  1970
> >
> /nix/store/fgkznmnz1swzp8ck75fa2zvj62pkjgvq-musl-x86_64-unknown-linux-musl-1.2.3/lib/ld-musl-x86_64.so.1
> > ```
> >
> > My fix (attached) is to use `umask 022`, which was already being used to
> > make directories. It's not practical to fix this by specifying the
> intended
> > permissions for this symlink, as setting link permissions requires the
> > nonstandard `-h` chmod flag, which presumably fails on other platforms.
> >
> > First discovered when cross-building on MacOS for linux:
> > https://github.com/NixOS/nixpkgs/issues/285141
> >
> > I've tested the fix works in nix. I am fairly confident the same issue
> > exists outside of Nix given the fix, but I haven't built musl before and
> > ran into unrelated errors.
> >
> > Thanks,
> >  - Tim
>
> Thanks for catching this. Do you think it might be better to put umask
> 000 inside the symlink case instead of just reusing the 022 from dir?
> 000 seems like what you actually want to fix the symlink behavior.
>
> Alternatively maybe we should set umask to the complement of the
> desired mode?
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 3396 bytes --]

Re: [musl] Bug: installed symlinks are unreadable on MacOS

[Rich Felker]

On Thu, Feb 01, 2024 at 09:39:56AM +1100, Tim Cuthbertson wrote:
> Yeah, setting it to `chmod 000` in just the symlink branch seems good to me
> too.
> 
> Looking at the script more closely, `mode` is always set and so I'm unclear
> why there is also a `umask 077` at all. Whatever permissions we create the
> file with, we `chmod` it explicitly before doing anything else.
> 
> Is that line just there to undo the potential change to `umask` in the
> mkdirp branch? If so, maybe that should be done explicitly by capturing the
> old umask? e.g:

No, it's so that the install.sh never exposes a file to users who
should not have access to it via the existing umask being more
permissive than the requested install mode. Normally this does not
matter for use as part of musl's install process, but the script is
written to be general and not have security bugs like that.

Rich

Re: [musl] Bug: installed symlinks are unreadable on MacOS

[Tim Cuthbertson]

[-- Attachment #1.1: Type: text/plain, Size: 1195 bytes --]

Ah that makes sense, attached an updated patch. I don't know whether the
`umask 077` after making the symlink is strictly necessary but it might
avoid nasty surprises later on in the script.

Cheers,
- Tim

On Thu, 1 Feb 2024 at 10:32, Rich Felker <dalias@libc.org> wrote:

> On Thu, Feb 01, 2024 at 09:39:56AM +1100, Tim Cuthbertson wrote:
> > Yeah, setting it to `chmod 000` in just the symlink branch seems good to
> me
> > too.
> >
> > Looking at the script more closely, `mode` is always set and so I'm
> unclear
> > why there is also a `umask 077` at all. Whatever permissions we create
> the
> > file with, we `chmod` it explicitly before doing anything else.
> >
> > Is that line just there to undo the potential change to `umask` in the
> > mkdirp branch? If so, maybe that should be done explicitly by capturing
> the
> > old umask? e.g:
>
> No, it's so that the install.sh never exposes a file to users who
> should not have access to it via the existing umask being more
> permissive than the requested install mode. Normally this does not
> matter for use as part of musl's install process, but the script is
> written to be general and not have security bugs like that.
>
> Rich
>

[-- Attachment #1.2: Type: text/html, Size: 1601 bytes --]

[-- Attachment #2: musl-chmod.patch --]
[-- Type: application/octet-stream, Size: 536 bytes --]

commit 60ab5657d006f36032fe5a348349f9c38330ed91
Author: Tim Cuthbertson <tim@gfxmonk.net>
Date:   Wed Jan 31 12:45:06 2024 +1100

    install.sh: clear umask when making a symlink, so permissions on MacOS match Linux

diff --git a/tools/install.sh b/tools/install.sh
index d913b60b..855a8ca2 100755
--- a/tools/install.sh
+++ b/tools/install.sh
@@ -48,7 +48,9 @@ trap 'rm -f "$tmp"' EXIT INT QUIT TERM HUP
 umask 077
 
 if test "$symlink" ; then
+umask 000
 ln -s "$1" "$tmp"
+umask 077
 else
 cat < "$1" > "$tmp"
 chmod "$mode" "$tmp"