* [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec
@ 2024-02-09 14:09 Michal Sieron
2024-02-09 15:57 ` [OE-core] " Ross Burton
0 siblings, 1 reply; 7+ messages in thread
From: Michal Sieron @ 2024-02-09 14:09 UTC (permalink / raw)
To: openembedded-core; +Cc: Michal Sieron
meson saves its temporary scripts in /tmp.
Similarly some recipies also do that (e.g. ccan in sbsigntool).
As this can lead to unexpected build failures with no simple way
to workaround, make such setup a fatal error.
Signed-off-by: Michal Sieron <michalwsieron@gmail.com>
---
meta/classes-global/sanity.bbclass | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/meta/classes-global/sanity.bbclass b/meta/classes-global/sanity.bbclass
index 1bd74e1935..205516bf6a 100644
--- a/meta/classes-global/sanity.bbclass
+++ b/meta/classes-global/sanity.bbclass
@@ -840,6 +840,21 @@ def check_sanity_everybuild(status, d):
status.addresult("Please use a umask which allows a+rx and u+rwx\n")
os.umask(omask)
+ # Ensure /tmp is NOT mounted with noexec
+ with open("/proc/mounts", "r") as f:
+ for line in f:
+ # format is described in fstab(5)
+ _, fs_file, _, fs_mntops, *_ = line.split()
+
+ # we only want to check /tmp
+ if fs_file != "/tmp":
+ continue
+
+ # iterate through the options from the end
+ for opt in reversed(fs_mntops.split(",")):
+ if opt == "noexec":
+ raise_sanity_error("/tmp shouldn't be mounted with noexec.", d)
+
if d.getVar('TARGET_ARCH') == "arm":
# This path is no longer user-readable in modern (very recent) Linux
try:
--
2.43.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [OE-core] [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec
2024-02-09 14:09 [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec Michal Sieron
@ 2024-02-09 15:57 ` Ross Burton
2024-02-21 7:18 ` ChenQi
0 siblings, 1 reply; 7+ messages in thread
From: Ross Burton @ 2024-02-09 15:57 UTC (permalink / raw)
To: michalwsieron@gmail.com; +Cc: openembedded-core@lists.openembedded.org
On 9 Feb 2024, at 14:09, Michal Sieron via lists.openembedded.org <michalwsieron=gmail.com@lists.openembedded.org> wrote:
> + # Ensure /tmp is NOT mounted with noexec
> + with open("/proc/mounts", "r") as f:
> + for line in f:
> + # format is described in fstab(5)
> + _, fs_file, _, fs_mntops, *_ = line.split()
> +
> + # we only want to check /tmp
> + if fs_file != "/tmp":
> + continue
> +
> + # iterate through the options from the end
> + for opt in reversed(fs_mntops.split(",")):
> + if opt == "noexec":
> + raise_sanity_error("/tmp shouldn't be mounted with noexec.", d)
> +
Alternatively, this is neater:
os.statvfs("/tmp").f_flag & os.ST_NOEXEC
Ross
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [OE-core] [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec
2024-02-09 15:57 ` [OE-core] " Ross Burton
@ 2024-02-21 7:18 ` ChenQi
2024-02-21 9:48 ` Ross Burton
0 siblings, 1 reply; 7+ messages in thread
From: ChenQi @ 2024-02-21 7:18 UTC (permalink / raw)
To: Ross Burton, michalwsieron@gmail.com
Cc: openembedded-core@lists.openembedded.org
Hi Michal,
I just noticed the change. I can't find the V2 in my mailbox, so I'm
going to reply here.
I'm a little concerned about forcing such requirement here. It does not
seem *necessary*.
As far as I know, the whole oe-core does not need /tmp to be exec. The
commit message says 'old meson', this means the current version of meson
works well, right?
Also, why is there 'no simple way to workaround'? Is the recipe
hardcoding '/tmp' instead of using API or command? Does exporting TMPDIR
work?
e.g.,
export TMPDIR="${B}/tmp"
Regards,
Qi
On 2/9/24 23:57, Ross Burton wrote:
> On 9 Feb 2024, at 14:09, Michal Sieron via lists.openembedded.org <michalwsieron=gmail.com@lists.openembedded.org> wrote:
>> + # Ensure /tmp is NOT mounted with noexec
>> + with open("/proc/mounts", "r") as f:
>> + for line in f:
>> + # format is described in fstab(5)
>> + _, fs_file, _, fs_mntops, *_ = line.split()
>> +
>> + # we only want to check /tmp
>> + if fs_file != "/tmp":
>> + continue
>> +
>> + # iterate through the options from the end
>> + for opt in reversed(fs_mntops.split(",")):
>> + if opt == "noexec":
>> + raise_sanity_error("/tmp shouldn't be mounted with noexec.", d)
>> +
> Alternatively, this is neater:
>
> os.statvfs("/tmp").f_flag & os.ST_NOEXEC
>
> Ross
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#195233): https://lists.openembedded.org/g/openembedded-core/message/195233
> Mute This Topic: https://lists.openembedded.org/mt/104258828/7304865
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [Qi.Chen@eng.windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [OE-core] [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec
2024-02-21 7:18 ` ChenQi
@ 2024-02-21 9:48 ` Ross Burton
2024-02-21 10:08 ` Alexander Kanavin
0 siblings, 1 reply; 7+ messages in thread
From: Ross Burton @ 2024-02-21 9:48 UTC (permalink / raw)
To: ChenQi; +Cc: michalwsieron@gmail.com, openembedded-core@lists.openembedded.org
On 21 Feb 2024, at 07:18, ChenQi <Qi.Chen@windriver.com> wrote:
> I just noticed the change. I can't find the V2 in my mailbox, so I'm going to reply here.
> I'm a little concerned about forcing such requirement here. It does not seem *necessary*.
> As far as I know, the whole oe-core does not need /tmp to be exec. The commit message says 'old meson', this means the current version of meson works well, right?
> Also, why is there 'no simple way to workaround'? Is the recipe hardcoding '/tmp' instead of using API or command? Does exporting TMPDIR work?
> e.g.,
> export TMPDIR="${B}/tmp”
You _can_ export TMPDIR but that has to be done on a per-recipe/class basis very carefully as TMPDIR means something else to Bitbake.
The problem is recipes that use mktemp to write files and execute them (be it shell scripts, or as a place to write C and then compile in the same directory). These will be in /tmp (again, we can’t set TMPDIR because for foolish historical reasons, TMPDIR is used by bitbake).
We first noticed this with Meson where noexec /tmp meant the configure tests failed. We worked around it at the time by assigning TMPDIR when calling Meson, but since them Meson writes to its own build tree now. This has been seen before though, but luckily noexec /tmp is fairly unusual so I doubt this will break many builds.
Ross
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [OE-core] [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec
2024-02-21 9:48 ` Ross Burton
@ 2024-02-21 10:08 ` Alexander Kanavin
2024-02-21 21:36 ` Randy MacLeod
0 siblings, 1 reply; 7+ messages in thread
From: Alexander Kanavin @ 2024-02-21 10:08 UTC (permalink / raw)
To: Ross Burton
Cc: ChenQi, michalwsieron@gmail.com,
openembedded-core@lists.openembedded.org
On Wed, 21 Feb 2024 at 10:48, Ross Burton <ross.burton@arm.com> wrote:
> You _can_ export TMPDIR but that has to be done on a per-recipe/class basis very carefully as TMPDIR means something else to Bitbake.
>
> The problem is recipes that use mktemp to write files and execute them (be it shell scripts, or as a place to write C and then compile in the same directory). These will be in /tmp (again, we can’t set TMPDIR because for foolish historical reasons, TMPDIR is used by bitbake).
>
> We first noticed this with Meson where noexec /tmp meant the configure tests failed. We worked around it at the time by assigning TMPDIR when calling Meson, but since them Meson writes to its own build tree now. This has been seen before though, but luckily noexec /tmp is fairly unusual so I doubt this will break many builds.
I'm actually curious where noexec /tmp can be observed. It does seem
rare, because I think it's the first time someone came up with a
sanity check for it. Perhaps it should be treated as a bug in that
respective environment/OS/container?
Alex
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [OE-core] [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec
2024-02-21 10:08 ` Alexander Kanavin
@ 2024-02-21 21:36 ` Randy MacLeod
2024-02-22 9:41 ` michalwsieron
0 siblings, 1 reply; 7+ messages in thread
From: Randy MacLeod @ 2024-02-21 21:36 UTC (permalink / raw)
To: alex.kanavin, Ross Burton, michalwsieron@gmail.com
Cc: ChenQi, openembedded-core@lists.openembedded.org
[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]
On 2024-02-21 5:08 a.m., Alexander Kanavin via lists.openembedded.org wrote:
> On Wed, 21 Feb 2024 at 10:48, Ross Burton<ross.burton@arm.com> wrote:
>> You _can_ export TMPDIR but that has to be done on a per-recipe/class basis very carefully as TMPDIR means something else to Bitbake.
>>
>> The problem is recipes that use mktemp to write files and execute them (be it shell scripts, or as a place to write C and then compile in the same directory). These will be in /tmp (again, we can’t set TMPDIR because for foolish historical reasons, TMPDIR is used by bitbake).
>>
>> We first noticed this with Meson where noexec /tmp meant the configure tests failed. We worked around it at the time by assigning TMPDIR when calling Meson, but since them Meson writes to its own build tree now. This has been seen before though, but luckily noexec /tmp is fairly unusual so I doubt this will break many builds.
> I'm actually curious where noexec /tmp can be observed. It does seem
> rare, because I think it's the first time someone came up with a
> sanity check for it. Perhaps it should be treated as a bug in that
> respective environment/OS/container?
We've been using noexec /tmp since 2019 with few if any problems
using:
meta-anaconda
meta-aws
meta-browser
meta-clang
meta-cloud-services
meta-dpdk
meta-imx
meta-intel
meta-intel-qat
meta-iot-cloud
meta-lat
meta-mingw
meta-openembedded
meta-qt6
meta-raspberrypi
meta-realtime
meta-secure-core
meta-security
meta-selinux
meta-tensorflow
meta-virtualization
meta-xilinx
meta-xilinx-tools
meta-yocto
Michal, what problem are you seeing?
../Randy
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#195965):https://lists.openembedded.org/g/openembedded-core/message/195965
> Mute This Topic:https://lists.openembedded.org/mt/104258828/3616765
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [randy.macleod@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
--
# Randy MacLeod
# Wind River Linux
[-- Attachment #2: Type: text/html, Size: 3935 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [OE-core] [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec
2024-02-21 21:36 ` Randy MacLeod
@ 2024-02-22 9:41 ` michalwsieron
0 siblings, 0 replies; 7+ messages in thread
From: michalwsieron @ 2024-02-22 9:41 UTC (permalink / raw)
To: Randy MacLeod; +Cc: alex.kanavin, Ross Burton, ChenQi, openembedded-core
> Michal, what problem are you seeing?
So originally I encountered this issue when building sbsigntool. Now I
see that I was simply using a modified version of an older recipe
revision.
If I were to use a somewhat recent one, I would have this change in
place
https://github.com/Wind-River/meta-secure-core/commit/f341b8653c65460d03a652a4af39fc876ea8a992
Anyway, when I talked about this on IRC, I suggested making this a
warning, but Ross and Richard wanted to hard error on this instead. I
guess we could make it a warning after all if that would break your
setup.
Michał
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-02-22 9:41 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-09 14:09 [PATCH] sanity.bbclass: raise_sanity_error if /tmp is noexec Michal Sieron
2024-02-09 15:57 ` [OE-core] " Ross Burton
2024-02-21 7:18 ` ChenQi
2024-02-21 9:48 ` Ross Burton
2024-02-21 10:08 ` Alexander Kanavin
2024-02-21 21:36 ` Randy MacLeod
2024-02-22 9:41 ` michalwsieron
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox