How to account for shell-session env vars, contexts with chroot

Question

So I'm working a script let's call it chroot-session-builder that mounts a file-system with a separate OS, and then logs me into a chrooted shell in the other file system. It works, but I'm a jerk and I want it work great.

The relevant part is this:

mkdir -p $mount_point/root/bin && \
cp chroot-env-setup.sh $mount_point/root/bin/ && \
chroot $mount_point bash -c /root/bin/chroot-env-setup.sh && \
chroot $mount_point

So I've passed in the chroot-env-setup.sh script. It runs and declares some stuff, the problem point being:

export HOME=/root
export PATH=$PATH:/root/bin

## *** More functions...
## *** Calls to other scripts...

exit 0;

Which exits the chroot context and brings me back to the running chroot-session-builder in the context of the shell original next calling:

chroot $mount_point

Bringing me into my chroot context.

Now it wasn't obvious to me until I ran some tests, and found this: How to correctly add a path to PATH?, that what's happening is that the export statement exposes the variable to the current shell session. And the reason for my confusion was overlooking that $HOME for root is /root anyways. (face-palm) and thus, anything I declare, I lose when I chroot back in.

I see two potential options here:

1) I can write can echo "export PATH:$PATH/root/bin" >> to /root/.profile, and when

This will not require me to source /root/.profile manually after I reenter the chroot context, because the new shell will read from /root/.profile on load.

2) The other option is if there a way to chroot $mount_point <with a command> and then stay in the chroot context from the script, so that the chroot-env-setup.sh script can do it's magic, and I don't have to worry about resetting anymore environmental changes or adding to files? (every file, settings adjustment I make when I enter, I have to account for and add to the clean up script before I save the file system.)

Answer 1

I get the feeling your subsequent questions stem from your initial question (but I cannot tell, not easy to read the train of thought)

The relevant part is this:

mkdir -p $mount_point/root/bin && \
cp chroot-env-setup.sh $mount_point/root/bin/ && \
chroot $mount_point bash -c /root/bin/chroot-env-setup.sh && \
chroot $mount_point

From that snippet, I think you mean to run a script in the chroot environment that does initial setup, then enter the chroot environment with an interactive command line.

So I've passed in the chroot-env-setup.sh script. It runs and declares some stuff, the problem point being:

export HOME=/root
export PATH=$PATH:/root/bin

## *** More functions...
## *** Calls to other scripts...

exit 0;

You have not clarified, but I presume this represents the contents of your session builder script ?

If so then yes, export VARNAME=value only applies to the shell session or script it runs in, not the session calling it.

The export keyword allows child processes to inherit the variable, otherwise it stays strictly on the scope of the running session / shell script. Environment variables NEVER bubble upwards to the caller's environment. That would be a catastrophic operational issue, not to mention a security minefield.

As regards where to put your variable definition:

All users can have a ~/.bashrc and ~/.profile file, even root, root is indeed a user, it just has special privileges and a home folder elsewhere.

Your bash session starts however with whatever HOME is currently set to. When calling chroot, you need to provide the intended target HOME

1. add export PATH=$PATH:/root/bin to $mountpoint/root/.bashrc
   • maybe also add echo Welcome to the chroot environment to the same .bashrc to see that it works
2. when calling chroot, you need to specify the home folder - not from within the chroot:
   • HOME=/root chroot $mountpoint

Indeed, you specify a variable and call a command on the same line. This sets the variable for that command's environment, not the current running environment.

For demo try

# Set var in current environment
MY_IS_SET=no

# Set var before calling env, which prints what its environment contains
MY_IS_SET=yes env | grep MY_IS_SET

# Check that current original environment is unchanged
echo $MY_IS_SET

The answers to the rest of your questions should flow from there ?