From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 29685294E4 for ; Wed, 31 Jan 2024 23:46:38 +0100 (CET) Received: (qmail 23937 invoked by uid 550); 31 Jan 2024 22:44:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15367 invoked from network); 31 Jan 2024 22:37:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gfxmonk.net; s=default; t=1706740814; bh=tj+1+v3BUI9f4NM3lSalOAIborG7B/PFXKTkUsJpnog=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=c/23KmNwZLahq0jig98tEznh9sFVlfbr38DuSb/R8DNdOx2qQDLa81VbvGMCj+fn9 G0k69+i1Fbe2lqAi3qoDI8dC0BmNNnHLzNq6tI8rNmai4To2GzU4/Y2QbwIH/RdxhU 7RN7cWINYX6/0crC/9pwpxtjUqOmx14xMabZrs/1trhSZyV5YOrgtK1kxahnNwUYPw IZ48aLafeHM2KX5abV7IkNxq0Bb51zvXChK0azlbY6C0eNEf22JJjShSPk2a+hM+RA 982G661A9ZUDq21FM7LsuYi6XYXN0mT+x8vQI6kWkWxK1x+io+mfB2SXiZkuq9ZYJw bSZ6Y289gQeKQ== X-Gm-Message-State: AOJu0Yw7uMArEiyMLtyb1aeI5N7VesFA3cXVL2tlPNkM8cs3FP8KNAmV C6v/gLWynYKsbE+RCle/G+wFozgQOrZZfmNmzvDsMOK0r3D+uzoBgfYBSzaDvBxOVjjrRd8Uc1E 8IfBXl5csvTIjPzP539KKG0FO5tg= X-Google-Smtp-Source: AGHT+IGaWWVXtMvyO4ubkUiO0evNw1+iipgQATi9qAKs+ApdzfhrpyBQ48WDg1LbIAjkd7BZT+0nlbmuyV6xgqNiPXg= X-Received: by 2002:a05:622a:1055:b0:42b:e7f2:bbd3 with SMTP id f21-20020a05622a105500b0042be7f2bbd3mr637552qte.27.1706740813364; Wed, 31 Jan 2024 14:40:13 -0800 (PST) MIME-Version: 1.0 References: <20240131134710.GU4163@brightrain.aerifal.cx> In-Reply-To: <20240131134710.GU4163@brightrain.aerifal.cx> From: Tim Cuthbertson Date: Thu, 1 Feb 2024 09:39:56 +1100 X-Gmail-Original-Message-ID: Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000e784cf0610458f1f" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [musl] Bug: installed symlinks are unreadable on MacOS --000000000000e784cf0610458f1f Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000e784cf0610458f1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, setting it to `chmod 000` in just the symlink branch= seems good to me too.

Looking at the script more closely, `mo= de` 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 explicitl= y before doing anything else.

Is that line just there to= undo the potential change to `umask` in the mkdirp branch? If so, maybe th= at should be done explicitly by capturing the old umask? e.g:
if test "$mkdirp" ; then
= umaskorig=3D"$(umask)"
umask 022
case "$2" in
= */*) mkdir -p "${dst%/*}" ;;
esac
umask "$umaskorig&qu= ot;
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 Ma= c 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-l= inux-musl-1.2.3/lib/ld-musl-x86_64.so.1':
> Permission denied
> lrwx------ 1 root wheel 7 Jan=C2=A0 1=C2=A0 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 i= ssue
> exists outside of Nix given the fix, but I haven't built musl befo= re and
> ran into unrelated errors.
>
> Thanks,
>=C2=A0 - 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
--000000000000e784cf0610458f1f--