From: Henning Schild <henning.schild@siemens.com>
To: <isar-users@googlegroups.com>
Subject: Re: [PATCH 2/2] images: wic: do not call wic with sudo anymore
Date: Wed, 31 Jan 2018 16:53:56 +0100 [thread overview]
Message-ID: <20180131165356.4323538c@mmd1pvb1c.ad001.siemens.net> (raw)
In-Reply-To: <20180131154838.14707-2-henning.schild@siemens.com>
I still prefer the almighty big sudo, this patch adds complexity and is
a hack. But i also think that touching contrib code in _any_ way is so
evil that any hack should be considered to avoid it.
Henning
Am Wed, 31 Jan 2018 16:48:38 +0100
schrieb Henning Schild <henning.schild@siemens.com>:
> Issues:
> 1. wic was called under sudo
> 2. wic and its plugins can use sudo to do whatever they want
>
> Impact:
> Issue 1 is addressed, but Issue 2 has always been there and has
> come to stay.
>
> Signed-off-by: Henning Schild <henning.schild@siemens.com>
> ---
> meta/classes/wic-img.bbclass | 17 ++++++++++++++++-
> scripts/wic_fakeroot | 37
> ++++++++++++++++++++++--------------- 2 files changed, 38
> insertions(+), 16 deletions(-)
>
> diff --git a/meta/classes/wic-img.bbclass
> b/meta/classes/wic-img.bbclass index 72779eb..444e003 100644
> --- a/meta/classes/wic-img.bbclass
> +++ b/meta/classes/wic-img.bbclass
> @@ -59,7 +59,22 @@ do_wic_image() {
> export BUILDDIR="${BUILDDIR}"
> export MTOOLS_SKIP_CHECK=1
>
> - sudo -E
> PATH="$PATH:/builder/isar/bitbake/bin:/builder/isar/scripts" /builder/isar/scripts/wic
> create ${WKS_FILE} --vars "${STAGING_DIR}/${MACHINE}/imgdata/" -o
> ${DEPLOY_DIR_IMAGE} -e ${IMAGE_BASENAME} ${WIC_CREATE_EXTRA_ARGS}
> + # Play a dirty trick to redirect "du" and "mkfs.*" to FAKEROOTCMD
> + WTOOLS_SYSROOT="${TMPDIR}/trick_wic/"
> + mkdir -p ${WTOOLS_SYSROOT}/sbin
> + mkdir -p ${WTOOLS_SYSROOT}/usr/bin
> + for fstype in btrfs ext2 ext3 ext4 vfat; do
> + ln -sf /builder/isar/scripts/${FAKEROOTCMD} \
> + ${WTOOLS_SYSROOT}/sbin/mkfs.${fstype}
> + done
> + ln -sf /builder/isar/scripts/${FAKEROOTCMD} \
> + ${WTOOLS_SYSROOT}/usr/bin/du
> +
> + echo "RECIPE_SYSROOT_NATIVE=\"${WTOOLS_SYSROOT}\"" >> \
> + ${STAGING_DIR}/${MACHINE}/imgdata/wic-tools.env
> +
> + export
> PATH="${WTOOLS_SYSROOT}/sbin:${WTOOLS_SYSROOT}/usr/sbin:${WTOOLS_SYSROOT}/usr/bin:${PATH}"
> + /builder/isar/scripts/wic create ${WKS_FILE} --vars
> "${STAGING_DIR}/${MACHINE}/imgdata/" -o ${DEPLOY_DIR_IMAGE} -e
> ${IMAGE_BASENAME} ${WIC_CREATE_EXTRA_ARGS} }
> addtask wic_image before do_build after do_copy_boot_files
> diff --git a/scripts/wic_fakeroot b/scripts/wic_fakeroot
> index 9e01c38..01865a0 100755
> --- a/scripts/wic_fakeroot
> +++ b/scripts/wic_fakeroot
> @@ -1,10 +1,11 @@
> #!/usr/bin/env python3
> #
> # wic needs a FAKEROOT cmd to run, the default is pseudo. In Isar we
> do/can not -# use pseudo. And we call wic as root to begin with, so
> this script could be a -# dummy doing nothing. It is almost a
> dummy ... -#
> -# If the fsck hack ever becomes obsolete, FAKEROOTCMD ?= "true;" can
> be used +# use pseudo at the moment.
> +# All wic calls to exec_native_cmd will end up here, if they wanted
> pseudo. +# They will get executed under sudo.
> +# In addition we prepend "du"s and "mkfs"s with a sudo, just like a
> Isar +# specific patch did before.
> #
> # This software is a part of Isar.
> # Copyright (C) 2018 Siemens AG
> @@ -15,23 +16,29 @@ import shutil
> import subprocess
>
> args = sys.argv
> -args.pop(0)
> -cmd = args[0]
> +args[0] = os.path.basename(args[0])
> +
> +if not (args[0].startswith('mkfs.') or args[0] == 'du'):
> + # the wrapper was not called directly and not for one of the
> known
> + # hacks
> + if args[0] != 'wic_fakeroot':
> + sys.exit(1)
> + args.pop(0)
>
> -# expect to be running as root
> -# we could loosen that and execv(sudo, args) but even some early
> -# "du"s fail, which do not use the fakeroot-wrapper
> -# i.e. in wics partition.py the "du -ks" fails on
> -# var/cache/apt/archives/partial
> -# rootfs/root ...
> -assert 'root' == os.environ["USER"]
> +cmd = args[0]
>
> # e2fsck <= 1.43.5 returns 1 on non-errors (stretch and before
> affected) # treat 1 as safe ... the filesystem was successfully
> repaired and is OK if cmd.startswith('fsck.'):
> - ret = subprocess.call(args)
> + ret = subprocess.call(['sudo'] + args)
> if ret == 0 or ret == 1:
> sys.exit(0)
> sys.exit(ret)
>
> -os.execv(shutil.which(cmd), args)
> +# now remove the previous 3 entries from PATH, the ones we used to
> trick some guys in here +path =
> ':'.join(os.environ['PATH'].split(':')[3:]) +path +=
> ":/builder/isar/bitbake/bin:/builder/isar/scripts" +
> +args = ['-E', 'PATH="%s"' % path ] + args
> +
> +os.execv(shutil.which('sudo'), args)
prev parent reply other threads:[~2018-01-31 15:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 15:48 [PATCH 1/2] wic: for pcibios boot plugins and wks files Henning Schild
2018-01-31 15:48 ` [PATCH 2/2] images: wic: do not call wic with sudo anymore Henning Schild
2018-01-31 15:53 ` Henning Schild [this message]
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=20180131165356.4323538c@mmd1pvb1c.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
/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