SUMMARY: you could use linux namespaces (see proof-of-concept below)
Agreed on all -- I've been complaining about the sad state of the DUP
environment for a long time.
My main complaints:
- /bin/sh is NOT bash and the code should reflect that (worst case this
reboots Debian nodes immediately for network DUPs due to code presumption
failures, thanks!)
- the entire DUP process should be reconsidered. offer PAYLOADS
separately from the DUP Deployment engine (which should be a reliable
generic linux deployment toolkit, that is linux distribution independent)
- /tmp should be replaced and referenced by:
TMPDIR=${TMPDIR:-/tmp}
- all "requirements" defined by stuff like
- testing for /etc/redhat-release (piffle)
- check that $TERM must be "xterm" , if not, then launch a separate
xterm (WTF?) (sorry, i almost never X11 tunnel due to the security risks)
are misguided at best and ultimately really unhelpful and worst case
just wrong.
etc, etc, etc...
Most of my complaints stem from my environment being 75%+ Debian -- and
yeah, i know Dell doesn't support it, but they COULD if they rearchitected
this stuff properly.
FWIW, i have my own custom deployment environment that leverages extracted
payload/* contents from extracted DUPs for:
- BIOS for pre UEFI systems (using libsmbios)
- megacli/storcli/perccli for LSI/Avago RAID controllers.
While Dell's DUPs have gotten easier and more reliable to deploy on Debian
in the past year or two (most BIOS updates now work again, and the Network
and BMC/iDRAC kits work for some definition of "Work" (coin-toss sometimes
as to wehther the iDRAC will update or not -- sometimes requiring several
reboots), the Avago situation has made things worse, as Avago seems to no
longer want to support Dell rebranded PERCs, thus requiring the new
'perccli' variant of 'storcli'. Fortunately, 'megacli' still works for
everything i've tried it on, for doing firmware loads. (independent of
Avago/Dell branding) But, Avago is making my life harder, because they're
no longer embedding the PCI vendor:device:subvendor:subdevice strings in
the ROM image files, so my script that processes them to create a
latest-supported ROM<->Device table to alert me to out-of-date systems
requires hand-assessment/modification :-(
Now, to the specific question at hand (/tmp being noexec) ...
Linux Namespaces can "solve" your problem if you are willing to always
launch the dup with a front-end launch script, something i *HAVE* to do on
Debian to "mangle" my operational environment so that the DUPs run. My
script does:
- temporarily replace /bin/sh (dash) with a symlink to /bin/bash (ugh)
- set my TERM envvar to "xterm"
- create a phony /etc/redhat-release so presumptions in scripts think
i'm running RHEL.
- cleanup after run
and i call it like "dup_run_debian {location-of-dup-file.bin}"
Anyway, a quick namespace test based upon:
https://blog.famzah.net/2014/06/04/private-tmp-mount-per-process-in-linux/
(NOTE: i haven't used this namespace stuff before, so i may not be doing
something optimally here)
WARNING: Debian ships with / being "shared" recursively by default, which
is at odds with the kernel
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739593
So, i had to:
mount --make-rprivate /tmp
before this script, because otherwise, it affects the parent process and
changes it for EVERYbody :-( (and then 'unshare doesn't unmount the
private instance afterwards, either, guh!)
root@jessie:/home/dowdy# mount -o remount,noexec /tmp
root@jessie:/home/dowdy# awk '$2=="/tmp"{print $0}' /proc/mounts
/dev/sda5 /tmp ext4 rw,noexec,relatime,data=ordered 0 0
root@jessie:/home/dowdy# /home/tmptest.sh
dowdy@jessie$ findmnt -o +TARGET,PROPAGATION /tmp
TARGET SOURCE FSTYPE
OPTIONS TARGET PROPAGATION
/tmp /dev/sda5 ext4
rw,noexec,relatime,data=ordered /tmp private
/tmp /dev/sda6[/tmp/tmp.dowdy_0i85mQv0] ext4
rw,relatime,data=ordered /tmp private
dowdy@jessie$ df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda6 36121108 2360792 31902372 7% /tmp
dowdy@jessie$ echo "echo SUCCESS" > /tmp/testing ; chmod 700 /tmp/testing ;
/tmp/testing
SUCCESS
That's opposed to the parenting process (and others), where i get
"permission denied" as expected.
Where the script /home/tmptest.sh is a slight mod to the example at the URL
above. (obviously, this would be a lot simpler if you're just doing this as
'root' -> 'root' for the DUP run:
------------------------------------------------
root@jessie:/home/dowdy# cat /home/tmptest.sh
#!/bin/sh
TARGET_USER='dowdy'
TARGET_CMD='/bin/bash' # but it can be any command
NEWTMP="$(mktemp -d /home/tmp/tmp.${TARGET_USER}_XXXXXXXX)" # securely
create a new empty tmp folder
chown "root:$TARGET_USER" "$NEWTMP"
chmod 770 "$NEWTMP"
unshare --mount -- /bin/bash -c "mount -o bind,noexec,nosuid,nodev
'$NEWTMP' /tmp && sudo -u '$TARGET_USER' $TARGET_CMD"
------------------------------------------------
--stephen
On Mon, Oct 24, 2016 at 7:21 AM, Robert Jacobson <[email protected]> wrote:
>
> This should be considered a bug in DUP. It should be easily resolvable by
> allowing users to customizing the temporary working directory; e.g. using
> an environment variable.
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:linux-poweredge-
> > [email protected]] On Behalf Of Thibaut Pouzet
> > Sent: Monday, October 24, 2016 3:47 AM
> > To: [email protected]
> > Subject: Re: [Linux-PowerEdge] Upgrading firmware under CentOS7
> >
> >
> > Le 21/10/2016 à 17:57, Davide Ferrari a écrit :
> >
> >
> > Hello,
> >
> >
> > CentOS7 comes with /tmp with no exec permissions by default, but
> all
> > Dell furmware upgrade pacakges uses /tmp as the default (and
> > uncustomizable) path to unpack and execute the actual FW upgrade binary
> > blob. Is there any official way to do it properly without remounting /tmp
> > with "exec" (or replacing /tmp with /var/tmp in the bash wrapper code
> > inside the package)?
> >
> >
> > Thanks
> >
> >
> > --
> >
> > Davide Ferrari
> >
> > Senior Systems Engineer
> >
> >
> >
> >
> > _______________________________________________
> > Linux-PowerEdge mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.us.dell.com/mailman/listinfo/linux-poweredge
> >
> > Hi,
> >
> > Not that I've heard of sorry. I do this and this works just fine : before
> > launching the update, I run :
> > sudo mount -o remount,exec /tmp
> >
> > Once I'm done :
> > sudo mount -o remount,noexec /tmp
> >
> > I'm not aware of any other magical solution
> >
> > Cheers
> >
> >
> > --
> > Thibaut Pouzet
> > Lyra Network
> > Expert Sécurité
> > (+33) 5 31 22 40 08
> > www.lyra-network.com <http://www.lyra-network.com>
>
>
> _______________________________________________
> Linux-PowerEdge mailing list
> [email protected]
> https://lists.us.dell.com/mailman/listinfo/linux-poweredge
>
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - [email protected] - http://www.ral.ucar.edu/~sdowdy/
_______________________________________________
Linux-PowerEdge mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
