From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
Siddhesh Poyarekar <siddhesh@sourceware.org>,
libc-alpha@sourceware.org
Cc: fweimer@redhat.com, carlos@redhat.com
Subject: Re: [PATCH 2/2] aarch64: Make glibc.mem.tagging SXID_ERASE
Date: Thu, 5 Oct 2023 09:19:09 +0100 [thread overview]
Message-ID: <ZR5xfdrc9aqiw/BW@arm.com> (raw)
In-Reply-To: <cd20d11d-00ff-4f67-aee3-4df1f78ec669@linaro.org>
The 10/04/2023 14:01, Adhemerval Zanella Netto wrote:
> On 04/10/23 11:51, Szabolcs Nagy wrote:
> >
> > personally i think setuid binaries should not touch the
> > env, just ignore it, so everything SXID_IGNORE.
>
> Do you mean just drop unsecvars and not filter out glibc environment variables
> for AT_SECURE?
i'd fix this in one place that makes the behaviour easy
to reason about: _dl_next_ld_env_entry in rtld should
just return empty in secure mode and same for getenv,
internally it should return empty.
then we know that nothing in libc can depend on the env.
(if something parses env directly that should be fixed)
if anything, there should be a whitelist, not blacklist
of env vars.
of course this changes behaviour, so if we want to be
bw compat then we have to live with the current unsetenv
logic.
next prev parent reply other threads:[~2023-10-05 8:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-03 20:11 [PATCH 0/2] make all tunables SXID_ERASE Siddhesh Poyarekar
2023-10-03 20:11 ` [PATCH 1/2] Make all malloc " Siddhesh Poyarekar
2023-10-03 20:11 ` [PATCH 2/2] aarch64: Make glibc.mem.tagging SXID_ERASE Siddhesh Poyarekar
2023-10-04 7:29 ` Szabolcs Nagy
2023-10-04 11:59 ` Siddhesh Poyarekar
2023-10-04 14:04 ` Szabolcs Nagy
2023-10-04 14:23 ` Siddhesh Poyarekar
2023-10-04 14:51 ` Szabolcs Nagy
2023-10-04 14:53 ` Siddhesh Poyarekar
2023-10-04 15:05 ` Siddhesh Poyarekar
2023-10-04 17:01 ` Adhemerval Zanella Netto
2023-10-05 8:19 ` Szabolcs Nagy [this message]
2023-10-05 12:55 ` Siddhesh Poyarekar
2023-10-05 13:59 ` Szabolcs Nagy
2023-10-05 14:05 ` Siddhesh Poyarekar
2023-10-05 18:31 ` Zack Weinberg
2023-10-05 19:11 ` Siddhesh Poyarekar
2023-10-06 12:25 ` Zack Weinberg
2023-10-06 12:41 ` Siddhesh Poyarekar
2023-10-06 17:10 ` Adhemerval Zanella Netto
2023-10-06 18:04 ` Siddhesh Poyarekar
2023-10-08 19:51 ` Michael Hudson-Doyle
2023-10-31 19:58 ` Zack Weinberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZR5xfdrc9aqiw/BW@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=adhemerval.zanella@linaro.org \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=siddhesh@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).