From 83a6c8d58b3209a1238d24b50c6b717a7c67d1b4 Mon Sep 17 00:00:00 2001 From: Denys Vlasenko Date: Sat, 5 Aug 2017 23:21:02 +0200 Subject: umount: make it NOEXEC Signed-off-by: Denys Vlasenko --- NOFORK_NOEXEC.lst | 2 +- util-linux/umount.c | 13 ++++++++++++- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/NOFORK_NOEXEC.lst b/NOFORK_NOEXEC.lst index fbba3adb3..8b35df289 100644 --- a/NOFORK_NOEXEC.lst +++ b/NOFORK_NOEXEC.lst @@ -378,7 +378,7 @@ udhcpc - daemon udhcpd - daemon udpsvd - daemon uevent - daemon -umount - noexec candidate, leaks: nested xmalloc +umount - noexec. leaks: nested xmalloc uname - NOFORK uncompress - runner unexpand - runner diff --git a/util-linux/umount.c b/util-linux/umount.c index 122c0f579..33667b13c 100644 --- a/util-linux/umount.c +++ b/util-linux/umount.c @@ -24,7 +24,18 @@ //config: help //config: Support -a option to unmount all currently mounted filesystems. -//applet:IF_UMOUNT(APPLET(umount, BB_DIR_BIN, BB_SUID_DROP)) +//applet:IF_UMOUNT(APPLET_NOEXEC(umount, umount, BB_DIR_BIN, BB_SUID_DROP, umount)) +/* + * On one hand, in some weird situations you'd want umount + * to not do anything surprising, to behave as a usual fork+execed executable. + * + * OTOH, there can be situations where execing would not succeed, or even hang + * (say, if executable is on a filesystem which is in trouble and accesses to it + * block in kernel). + * In this case, you might be actually happy if your standalone bbox shell + * does not fork+exec, but only forks and calls umount_main() which it already has! + * Let's go with NOEXEC. + */ //kbuild:lib-$(CONFIG_UMOUNT) += umount.o -- cgit v1.2.3