All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Garman <scott.a.garman@intel.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] runqemu-export-rootfs and friends: don't put pseudo db in target fs
Date: Wed, 22 Aug 2012 09:34:35 -0700	[thread overview]
Message-ID: <50350A1B.4060505@intel.com> (raw)
In-Reply-To: <511616ed1761453ec1323aa945c559ca6cafffd1.1345573717.git.peter.seebach@windriver.com>

On 08/21/2012 11:31 AM, Peter Seebach wrote:
> In a few places, we have scripts which use <rootfs>/var/pseudo for
> the pseudo state directory controlling a given filesystem. This
> seems possibly risky because it means that stuff running under
> qemu or whatnot could wipe out the data being used to handle that
> rootfs.
>
> Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
> ---
>   .../installer/adt-installer/scripts/extract_rootfs |    7 +++----
>   scripts/runqemu-export-rootfs                      |    2 +-
>   scripts/runqemu-extract-sdk                        |   13 +++++++------
>   3 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs b/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs
> index 62dc170..0bbbeef 100755
> --- a/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs
> +++ b/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs
> @@ -28,7 +28,6 @@ extract_rootfs()
>     native_sysroot=$3
>     target_sysroot=$2
>     PSEUDO_COMMAND="$native_sysroot/usr/bin/pseudo"
> -  PSEUDO_OPTS="-P $natvie_sysroot/usr"
>     TAR_OPTS="-xjf"
>     PSEUDO_OPTS="-P $native_sysroot/usr"
>
> @@ -46,9 +45,9 @@ extract_rootfs()
>       mkdir -p "$target_sysroot"
>     fi
>
> -  mkdir -p "$target_sysroot/var/pseudo"
> -  touch "$target_sysroot/var/pseudo/pseudo.pid"
> -  PSEUDO_LOCALSTATEDIR="$target_sysroot/var/pseudo"
> +  mkdir -p "$target_sysroot/../pseudo_state"
> +  touch "$target_sysroot/../pseudo_state/pseudo.pid"
> +  PSEUDO_LOCALSTATEDIR="$target_sysroot/../pseudo_state"
>     export PSEUDO_LOCALSTATEDIR

This would mean that if someone tried to put multiple rootfs directories 
in the same subdirectory, they could clobber each other's pseudo_state 
data, correct? Putting multiple rootfs directories in the same subdir is 
a common use case already, I don't think we could break that.

If you appended the top-level rootfs directory name to ../pseudo_state, 
e.g, ../pseudo_state_<dirname>, that would keep the pseudo_state 
directories separate and make it fairly obvious what rootfs they 
belonged to.

Also, neither of these schemes would support having $target_sysroot 
directly under / (though I'm not sure why someone would do that).

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center



  reply	other threads:[~2012-08-22 16:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-21 18:31 [PATCH 0/1] Move PSEUDO_LOCALSTATEDIR outside rootfs Peter Seebach
2012-08-21 18:31 ` [PATCH 1/1] runqemu-export-rootfs and friends: don't put pseudo db in target fs Peter Seebach
2012-08-22 16:34   ` Scott Garman [this message]
2012-08-22 19:20     ` Peter Seebach
2012-08-22 19:39     ` Richard Purdie
2012-08-27 16:17       ` Peter Seebach
  -- strict thread matches above, loose matches on Subject: below --
2012-08-23  1:47 [PATCH 0/1] v2: Move pseudo directory out of its filesystem Peter Seebach
2012-08-23  1:47 ` [PATCH 1/1] runqemu-export-rootfs and friends: don't put pseudo db in target fs Peter Seebach
2012-08-24  7:31   ` Scott Garman
2012-08-24 19:55   ` Peter Seebach
2012-08-27 18:32 [PATCH 0/1] v3: Move pseudo localstatedir outside of rootfs Peter Seebach
2012-08-27 18:32 ` [PATCH 1/1] runqemu-export-rootfs and friends: don't put pseudo db in target fs Peter Seebach

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=50350A1B.4060505@intel.com \
    --to=scott.a.garman@intel.com \
    --cc=openembedded-core@lists.openembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.