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 6243322A87 for ; Fri, 2 Feb 2024 03:54:06 +0100 (CET) Received: (qmail 19828 invoked by uid 550); 2 Feb 2024 02:51:34 -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 8160 invoked from network); 2 Feb 2024 02:40:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gfxmonk.net; s=default; t=1706841762; bh=yRubn0JNXXzvC1jBuxyRLNNyi3X0LOvk+Q8/g5beCLs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cXGv6fqFNoQ9u23T8VwC0VE+L3I3cK3pS9CnK4jjUcEMLyK9wKq/KWyQ9BhOCJevk y4YjVzoLc6D8t+FrjzwcdTeJKTYSZBhBjs3fI3RKU/YgpyauvCR8uhWNbyMJkCXZwj EG0486lNsj6tDHZvtoUqP23HXQJOP7PgecmbYz0axGL9kp8kQ2dcRg6YJeRU5qQjFD wXbhHz0hHK7/lIS1GQ47FgpIoZ1o2680YPZEpqCFXUtDfo7wL3xQRzQO072jHOYd+P NK7SeQh4ckYurHXNekPPBDE8CPxLqQDzLiTrc7AyJru0xZevSIvJmZE/47AM6Yc77g q3molC3K0D0hg== X-Gm-Message-State: AOJu0YyBp+mOAXsn+IHQ7lZE2n6nTKQw2X2cwWmY4aC/C3GUrWfgmzW2 xxXpp64ivyarhconP/1hSAvtXbk+i0p+ZbXbLn5g1W1gCzCErga0ghrqwQuc+T8ankL+QnyztZ4 5C5rSeZZYaR63iNjV+z662m5C0U4= X-Google-Smtp-Source: AGHT+IFLOxBm7a5MCqngEv21MIueGttPqiL4bSYMpx7lJoF25tGxbxpQPv72sXozMs8PzQMQtuIZRsreuKF4ybtuVWw= X-Received: by 2002:a05:622a:150:b0:42a:b843:e0b2 with SMTP id v16-20020a05622a015000b0042ab843e0b2mr898261qtw.26.1706841761518; Thu, 01 Feb 2024 18:42:41 -0800 (PST) MIME-Version: 1.0 References: <20240131134710.GU4163@brightrain.aerifal.cx> <20240131233251.GZ22081@brightrain.aerifal.cx> In-Reply-To: <20240131233251.GZ22081@brightrain.aerifal.cx> From: Tim Cuthbertson Date: Fri, 2 Feb 2024 13:42:24 +1100 X-Gmail-Original-Message-ID: Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/mixed; boundary="000000000000e245df06105d10d1" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [musl] Bug: installed symlinks are unreadable on MacOS --000000000000e245df06105d10d1 Content-Type: multipart/alternative; boundary="000000000000e245dd06105d10cf" --000000000000e245dd06105d10cf Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000e245dd06105d10cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah that makes sense, attached an updated patch. I don'= t know whether the `umask 077` after making the symlink is strictly necessa= ry 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:
<= /div>
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 capturin= g 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
--000000000000e245dd06105d10cf-- --000000000000e245df06105d10d1 Content-Type: application/octet-stream; name="musl-chmod.patch" Content-Disposition: attachment; filename="musl-chmod.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ls41h4220 Y29tbWl0IDYwYWI1NjU3ZDAwNmYzNjAzMmZlNWEzNDgzNDlmOWMzODMzMGVkOTEKQXV0aG9yOiBU aW0gQ3V0aGJlcnRzb24gPHRpbUBnZnhtb25rLm5ldD4KRGF0ZTogICBXZWQgSmFuIDMxIDEyOjQ1 OjA2IDIwMjQgKzExMDAKCiAgICBpbnN0YWxsLnNoOiBjbGVhciB1bWFzayB3aGVuIG1ha2luZyBh IHN5bWxpbmssIHNvIHBlcm1pc3Npb25zIG9uIE1hY09TIG1hdGNoIExpbnV4CgpkaWZmIC0tZ2l0 IGEvdG9vbHMvaW5zdGFsbC5zaCBiL3Rvb2xzL2luc3RhbGwuc2gKaW5kZXggZDkxM2I2MGIuLjg1 NWE4Y2EyIDEwMDc1NQotLS0gYS90b29scy9pbnN0YWxsLnNoCisrKyBiL3Rvb2xzL2luc3RhbGwu c2gKQEAgLTQ4LDcgKzQ4LDkgQEAgdHJhcCAncm0gLWYgIiR0bXAiJyBFWElUIElOVCBRVUlUIFRF Uk0gSFVQCiB1bWFzayAwNzcKIAogaWYgdGVzdCAiJHN5bWxpbmsiIDsgdGhlbgordW1hc2sgMDAw CiBsbiAtcyAiJDEiICIkdG1wIgordW1hc2sgMDc3CiBlbHNlCiBjYXQgPCAiJDEiID4gIiR0bXAi CiBjaG1vZCAiJG1vZGUiICIkdG1wIgo= --000000000000e245df06105d10d1--