From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6449667588399038464 X-Received: by 10.25.196.9 with SMTP id u9mr2348704lff.13.1501680255671; Wed, 02 Aug 2017 06:24:15 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.33.81 with SMTP id h78ls415556ljh.19.gmail; Wed, 02 Aug 2017 06:24:15 -0700 (PDT) X-Received: by 10.46.71.5 with SMTP id u5mr2824831lja.2.1501680255195; Wed, 02 Aug 2017 06:24:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501680255; cv=none; d=google.com; s=arc-20160816; b=OnpjTrGX9Fys2JX4DghlzNPSD8vPk1K53XDrm7/XA3PBAxZT0QTKirol5kXYF9WFlo +Z6FRnqrbe9gCmdFLZRG1EdX2Vrl9UbnDXCOqMjbfgslzpPSwV9FkABB3zkCJ6E1g8+4 I/saNt3mpvs7IjNJRl2gBgC+2JIKePe5Gbg9a4LXjKk6QKhwG3e2Zt9JM7vtdwhC0K4N WeY871VQ0EtK9LFaC1OAHdQMkTg09gYQB6HoRVfGM1ADbol+MzQjw59FHi//dEajK8rz Y3YjuVWA6rSVtFIC1QCX088N7f07uc2sKlpRggjjTriMFct51DeVFoK+Ijm4eK7Z87wH xH9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:content-disposition:content-description:mime-version :message-id:subject:to:from:date:arc-authentication-results; bh=oMvV/bLrL8cknIXvZSz7Mlv5I9uAm7BufmpzNbD5pNw=; b=uop3MjJk4wOmdsGeQhonUFQO64U7zjudFSTFeIDClkx5GgOIDbOByCvNnSNmYhB+Qz 4sPPvn2mFk2FPKZtVP4nEqlVPlCxi2iOq0jCEsS7MPak6dNx98gHLA2YY7fDWJdjKSDS ZnfEy2frOu3AFkmL0bRNAP2RxaMm86YQdC8KJ999DW3XjV/MFEM5YK6i885AM9rJEVhp buORiF7tgzb8Z8YJ2Y/xJqwSmtfRB52l6tG/5UeeInfWZF/lXTy+OGcw/WPd41uBVKVT ypWS9xTJ7Bkex6XAwcuFsM6GOCOppRYQsYz8okd7WWcDJYcg+o3FvcQt3QgouyfsCSUN EoIw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of andreas.reichel.ext@siemens.com) smtp.mailfrom=andreas.reichel.ext@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id v142si975209wmv.8.2017.08.02.06.24.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 06:24:15 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of andreas.reichel.ext@siemens.com) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of andreas.reichel.ext@siemens.com) smtp.mailfrom=andreas.reichel.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id v72DOEAP028633 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 2 Aug 2017 15:24:14 +0200 Received: from iiotirae (golem.ppmd.siemens.net [139.25.69.162]) by mail1.sbs.de (8.15.2/8.15.2) with SMTP id v72DOEcK021558 for ; Wed, 2 Aug 2017 15:24:14 +0200 Date: Wed, 2 Aug 2017 15:24:14 +0200 From: Andreas Reichel To: isar-users@googlegroups.com Subject: Integration of Pseudo into Isar Message-ID: <20170802132413.GA25215@iiotirae> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: message Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-TUID: qsd7OUo4BSsW # Integrating pseudo into isar Idea was to exchange `sudo` by `pseudo`. The function of `pseudo` is to intercept system calls and file accesses by preloading a library. All such operations are recorded in a database. For this to work, a `PSEUDO_PREFIX` variable must be seet, which is `/` if `pseudo` is installed to the default location. # Given test configuration # - Docker container based on debian 9 - `multistrap` from Siemens Debian repository - `pseudo` from Siemens Debian repository Using the following multistrap configuration named `simple-config`: ``` [General] unpack=true bootstrap=Debian aptsources=Debian noauth=true [Debian] packages= source=http://ftp.de.debian.org/debian suite=stretch ``` Inside chroot (which is inside pseudo): ``` # mkdir rootfs # multistrap -f simple-config -d rootfs ``` # Results # * Error during package configuration. (Cannot write to `/etc/ld.so.cache~`) This error can be tracked down to `ldconfig`. It turned out that `ldconfig` is linked *statically*. Which means, its file accesses cannot be intercepted by LDPRELOAD, which is only for dynamically linked binaries. Thus, wether being in a pseudo chroot or not, `ldconfig` will always access `/etc/ld.so.cache~` on the host, which fails. This is *NOT* a question of the Debian version and not a bug in `dpkg --configure -a`, which calls `ldconfig` internally. * Extremely odd behaviour within `chroot` within `pseudo`: ``` $ pseudo # chroot rootfs # export PATH=/sbin:/bin # ldconfig Can't create temporary cache file /etc/ld.so.cache~ ``` Idea was then to rename `ldconfig` to `ldconfig_` and create a symbolic link to `/bin/true` to mimic successful execution of `ldconfig`. ``` $ sudo mv rootfs/sbin/ldconfig rootfs/sbin/ldconfig_ $ sudo ln -s /bin/true rootfs/sbin/ldconfig ``` Here, behavior becomes very odd: ``` $ pseudo # chroot rootfs # export PATH=/sbin:/bin # ldconfig /bin/sh: 16: ldconfig: not found ``` Although it is in path... ``` # /sbin/ldconfig /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied ``` So this is not our symbolic link but the real ldconfig from the host ``` # cd /sbin # ./ldconfig # ``` This works and returns `true`. ``` # cd / # /sbin/ldconfig /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied # sbin/ldconfig # ``` So a relative path works, but an absolute path does not. Even more funny is: ``` # exec sh # exit $ ``` The first `exec` replaces the current shell with `sh` from *OUTSIDE* of the `chroot`. The `exit` then exits the `pseudo` environment instead of the `chroot` environment. # Summary # * operations with `chroot inside pseudo` are completely messed-up. * `ldconfig` will never work with `pseudo` since it is static. But if packets are not configured, initramfs is not generated, etc... # Ideas # * Yocto Morty uses pseudo with own patches, which may solve some or all issues * Do not use multistrap but another tool * Stracing / Kernel tracing to analyze problem more deeply Kind regards, Andreas -- Andreas Reichel Dipl.-Phys. (Univ.) Software Consultant Andreas.Reichel@tngtech.com, +49-174-3180074 TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082