libpam: reproducibility: Fix host umask leakage at patch-time

Submitted by douglas.royds on Dec. 20, 2018, 5:40 a.m. | Patch ID: 157351

Details

Message ID 20181220054044.29476-1-douglas.royds@taitradio.com
State New
Headers show

Commit Message

douglas.royds Dec. 20, 2018, 5:40 a.m.
The patch file pam-security-abstract-securetty-handling.patch creates a new
file (tty_secure.c) at patch-time, so its permissions are subject to the host
umask. This file is later copied into the -dbg package with no change in
permissions.

Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
---
 meta/recipes-extended/pam/libpam_1.3.0.bb | 3 +++
 1 file changed, 3 insertions(+)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-extended/pam/libpam_1.3.0.bb b/meta/recipes-extended/pam/libpam_1.3.0.bb
index 3aec2cdb4c..292b570e11 100644
--- a/meta/recipes-extended/pam/libpam_1.3.0.bb
+++ b/meta/recipes-extended/pam/libpam_1.3.0.bb
@@ -49,6 +49,9 @@  S = "${WORKDIR}/Linux-PAM-${PV}"
 
 inherit autotools gettext pkgconfig
 
+# We create a new file (tty_secure.c) from pam-security-abstract-securetty-handling.patch
+do_patch[umask] = "022"
+
 PACKAGECONFIG[audit] = "--enable-audit,--disable-audit,audit,"
 
 PACKAGES += "${PN}-runtime ${PN}-xtests"

Comments

Ross Burton Dec. 20, 2018, 1:04 p.m.
Why is this libpam specific and not a general issue that the umask
needs to be set in patch.bbclass?

Ross
On Thu, 20 Dec 2018 at 05:41, Douglas Royds <douglas.royds@taitradio.com> wrote:
>
> The patch file pam-security-abstract-securetty-handling.patch creates a new
> file (tty_secure.c) at patch-time, so its permissions are subject to the host
> umask. This file is later copied into the -dbg package with no change in
> permissions.
>
> Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
> ---
>  meta/recipes-extended/pam/libpam_1.3.0.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-extended/pam/libpam_1.3.0.bb b/meta/recipes-extended/pam/libpam_1.3.0.bb
> index 3aec2cdb4c..292b570e11 100644
> --- a/meta/recipes-extended/pam/libpam_1.3.0.bb
> +++ b/meta/recipes-extended/pam/libpam_1.3.0.bb
> @@ -49,6 +49,9 @@ S = "${WORKDIR}/Linux-PAM-${PV}"
>
>  inherit autotools gettext pkgconfig
>
> +# We create a new file (tty_secure.c) from pam-security-abstract-securetty-handling.patch
> +do_patch[umask] = "022"
> +
>  PACKAGECONFIG[audit] = "--enable-audit,--disable-audit,audit,"
>
>  PACKAGES += "${PN}-runtime ${PN}-xtests"
> --
> 2.17.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Richard Purdie Dec. 20, 2018, 1:06 p.m.
On Thu, 2018-12-20 at 18:40 +1300, Douglas Royds wrote:
> The patch file pam-security-abstract-securetty-handling.patch creates
> a new
> file (tty_secure.c) at patch-time, so its permissions are subject to
> the host
> umask. This file is later copied into the -dbg package with no change
> in
> permissions.
> 
> Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
> ---
>  meta/recipes-extended/pam/libpam_1.3.0.bb | 3 +++
>  1 file changed, 3 insertions(+)

I've noticed you're sending a number of reproducibility patches. Would
you have any interest in helping us develop some reproducibility tests
for OE-Core in meta/lib/oeqa, probably as part of oe-selftest?

Cheers,

Richard
douglas.royds Dec. 20, 2018, 8:26 p.m.
libpam is unusual in having a patch that creates an entirely new file 
(tty_secure.c). If that patch eventually goes, then this umask setting 
can go as well.

I haven't come across any other cases of a patch creating a file, but if 
there are, then we could certainly move this setting. Perhaps we should 
wait until others emerge.


On 21/12/18 2:04 AM, Burton, Ross wrote:

> Why is this libpam specific and not a general issue that the umask
> needs to be set in patch.bbclass?
>
> Ross
> On Thu, 20 Dec 2018 at 05:41, Douglas Royds <douglas.royds@taitradio.com> wrote:
>> The patch file pam-security-abstract-securetty-handling.patch creates a new
>> file (tty_secure.c) at patch-time, so its permissions are subject to the host
>> umask. This file is later copied into the -dbg package with no change in
>> permissions.
>>
>> Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
>> ---
>>   meta/recipes-extended/pam/libpam_1.3.0.bb | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/meta/recipes-extended/pam/libpam_1.3.0.bb b/meta/recipes-extended/pam/libpam_1.3.0.bb
>> index 3aec2cdb4c..292b570e11 100644
>> --- a/meta/recipes-extended/pam/libpam_1.3.0.bb
>> +++ b/meta/recipes-extended/pam/libpam_1.3.0.bb
>> @@ -49,6 +49,9 @@ S = "${WORKDIR}/Linux-PAM-${PV}"
>>
>>   inherit autotools gettext pkgconfig
>>
>> +# We create a new file (tty_secure.c) from pam-security-abstract-securetty-handling.patch
>> +do_patch[umask] = "022"
>> +
>>   PACKAGECONFIG[audit] = "--enable-audit,--disable-audit,audit,"
>>
>>   PACKAGES += "${PN}-runtime ${PN}-xtests"
>> --
>> 2.17.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Ross Burton Dec. 20, 2018, 8:37 p.m.
On Thu, 20 Dec 2018 at 20:26, Douglas Royds <douglas.royds@taitradio.com> wrote:
> libpam is unusual in having a patch that creates an entirely new file
> (tty_secure.c). If that patch eventually goes, then this umask setting
> can go as well.
>
> I haven't come across any other cases of a patch creating a file, but if
> there are, then we could certainly move this setting. Perhaps we should
> wait until others emerge.

I definitely wouldn't want to make the assumption that libpam is the
only recipe of all time that will create a file.

Ross
Ross Burton Dec. 20, 2018, 8:39 p.m.
On Thu, 20 Dec 2018 at 20:37, Burton, Ross <ross.burton@intel.com> wrote:
> > I haven't come across any other cases of a patch creating a file, but if
> > there are, then we could certainly move this setting. Perhaps we should
> > wait until others emerge.
>
> I definitely wouldn't want to make the assumption that libpam is the
> only recipe of all time that will create a file.

Quick grep for chunks that have /dev/null as the input, so are creating files:

$ git grep -l -- '--- /dev/null'
recipes-bsp/keymaps/files/GPLv2.patch
recipes-bsp/v86d/v86d/Update-x86emu-from-X.org.patch
recipes-connectivity/bind/bind/make-etc-initd-bind-stop-work.patch
recipes-connectivity/openssl/openssl10/debian1.0.2/version-script.patch
recipes-core/gettext/gettext-0.19.8.1/fix-CVE-2018-18751.patch
recipes-core/glibc/glibc/0006-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch
recipes-core/glibc/glibc/0018-eglibc-Cross-building-and-testing-instructions.patch
recipes-core/glibc/glibc/0019-eglibc-Help-bootstrap-cross-toolchain.patch
recipes-core/glibc/glibc/0022-eglibc-Forward-port-cross-locale-generation-support.patch
recipes-core/initscripts/initscripts-1.0/GPLv2.patch
recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
recipes-core/systemd/systemd/0004-add-fallback-parse_printf_format-implementation.patch
recipes-core/udev/eudev/0014-Revert-rules-remove-firmware-loading-rules.patch
recipes-core/udev/eudev/Revert-udev-remove-userspace-firmware-loading-suppor.patch
recipes-devtools/build-compare/files/Rename-rpm-check.sh-to-pkg-diff.sh.patch
recipes-devtools/docbook-xml/docbook-xml-dtd4/docbook-xml-update-catalog.xml.patch
recipes-devtools/elfutils/files/debian/arm_backend.diff
recipes-devtools/elfutils/files/debian/hppa_backend.diff
recipes-devtools/elfutils/files/debian/mips_backend.diff
recipes-devtools/go/go-dep/0001-Add-support-for-mips-mips64.patch
recipes-devtools/patch/patch/0004-Fix-arbitrary-command-execution-in-ed-style-patches-.patch
recipes-devtools/perl/perl/0001-Skip-various-tests-if-PERL_BUILD_PACKAGING-is-set.patch
recipes-devtools/perl/perl/debian/fixes/podman-pipe.diff
recipes-devtools/python/python/0001-2.7-bpo-34623-Use-XML_SetHashSalt-in-_elementtree-GH.patch
recipes-devtools/python/python/0001-bpo-33354-Fix-test_ssl-when-a-filename-cannot-be-enc.patch
recipes-devtools/python/python/0001-bpo-33570-TLS-1.3-ciphers-for-OpenSSL-1.1.1-GH-6976-.patch
recipes-devtools/python/python/0001-closes-bpo-34540-Convert-shutil._call_external_zip-t.patch
recipes-devtools/python/python/float-endian.patch
recipes-devtools/python/python3-iniparse/0001-Add-python-3-compatibility.patch
recipes-devtools/python/python3/0002-bpo-29136-Add-TLS-1.3-cipher-suites-and-OP_NO_TLSv1_.patch
recipes-devtools/python/python3/0003-bpo-32947-Fixes-for-TLS-1.3-and-OpenSSL-1.1.1-GH-876.patch
recipes-devtools/python/python3/0005-bpo-30714-ALPN-changes-for-OpenSSL-1.1.0f-2305.patch
recipes-devtools/python/python3/float-endian.patch
recipes-devtools/qemu/qemu/0013-cpus.c-Add-error-messages-when-qemi_cpu_kick_thread-.patch
recipes-devtools/syslinux/syslinux/0006-linux-syslinux-implement-write_to_ext-and-add-syslin.patch
recipes-devtools/systemd-bootchart/systemd-bootchart/0002-musl-does-not-provide-printf-h.patch
recipes-extended/libaio/libaio/00_arches.patch
recipes-extended/libsolv/libsolv/0001-Add-fallback-fopencookie-implementation.patch
recipes-extended/ltp/ltp/0001-syscalls-fcntl-make-OFD-command-use-fcntl64-syscall-.patch
recipes-extended/pam/libpam/0001-Add-support-for-defining-missing-funcitonality.patch
recipes-extended/pam/libpam/pam-security-abstract-securetty-handling.patch
recipes-extended/slang/slang/terminfo_fixes.patch
recipes-gnome/gdk-pixbuf/gdk-pixbuf/extending-libinstall-dependencies.patch
recipes-gnome/gtk+/gtk+3/0003-Add-disable-opengl-configure-option.patch
recipes-graphics/mesa/mesa-demos/0001-mesa-demos-Add-missing-data-files.patch
recipes-graphics/wayland/weston/0001-make-error-portable.patch
recipes-graphics/x11-common/xserver-nodm-init/gplv2-license.patch
recipes-graphics/xorg-lib/libx11/X18NCMSstubs.patch
recipes-kernel/modutils-initscripts/files/PD.patch
recipes-multimedia/libid3tag/libid3tag/addpkgconfig.patch
recipes-support/attr/attr/attr-Missing-configure.ac.patch
recipes-support/gpgme/gpgme/0001-pkgconfig.patch
recipes-support/libassuan/libassuan/libassuan-add-pkgconfig-support.patch
recipes-support/libfm/libfm-extra/0001-nls.m4-Take-it-from-gettext-0.15.patch
recipes-support/libgcrypt/files/0001-Add-and-use-pkg-config-for-libgcrypt-instead-of-conf.patch
recipes-support/libgpg-error/libgpg-error/pkgconfig.patch
recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
recipes-support/liburcu/files/Add-support-for-the-RISC-V-architecture.patch
recipes-support/libxslt/libxslt/fix-rvts-handling.patch
recipes-support/npth/npth/pkgconfig.patch

Ross
douglas.royds Dec. 20, 2018, 8:40 p.m.
On 21/12/18 9:37 AM, Burton, Ross wrote:

> On Thu, 20 Dec 2018 at 20:26, Douglas Royds <douglas.royds@taitradio.com> wrote:
>> libpam is unusual in having a patch that creates an entirely new file
>> (tty_secure.c). If that patch eventually goes, then this umask setting
>> can go as well.
>>
>> I haven't come across any other cases of a patch creating a file, but if
>> there are, then we could certainly move this setting. Perhaps we should
>> wait until others emerge.
> I definitely wouldn't want to make the assumption that libpam is the
> only recipe of all time that will create a file.


No indeed. There are very likely others already, libpam is just the one 
I happened to stumble across. I'll shift the setting.