1

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.)

2

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 ?

  • Yeah, I have a lot of questions, this is the first robust thing I've written in bash. I've got solid clarification on the in's and out's of variable scoping now. It's more the entering a chroot context 'on the wings of a command' so to speak. You're right about placing it in the mounted fs before I chroot in. If I place the call to the 'chroot setup script' in /root/.profile it will execute when I enter chroot, and I can skip the hacky steps. Then if I add the cleanup script to /root/.bash_logout, I can run the cleaning script automatically on exit. Sorry, I was such a confusing mess. – blanket_cat Apr 20 '17 at 11:33
  • 1
    Not sure what you're trying to clean up ? I would imagine the original set up script would be for setting up the chroot environment once and for all ? After that, whatever env settings you make inside the chroot won't bleed out to the parent environment... Unless of course you're wanting to re-initialize the environment for the next time you logged in, in which case, it could be included in the setu pscript if that too runs every time.... – taifwa Apr 20 '17 at 12:55
  • Yeah the setup script is copies everything I need into the instance every run. See I'm building my own hardened distro as a side-project. Something where I can learn a lot and have something to show for it in the end. Very aware that tons of tools already exist for this express purpose, but this is so much more fulfilling than reading another cert manual, or step-by-step tutorial. I've got it setup that I can mount the live iso, make changes, clean up, and repackage it. But the thing is, as my decisions about what I want it be evolve, the config files the setup script loads change. – blanket_cat Apr 20 '17 at 13:29
  • And I'm learning (and more importantly retaining) an incredible amount of new bash tricks, just from trying to hone to build tools. – blanket_cat Apr 20 '17 at 13:32
  • I am intrigued. If you're posting any source anywhere I'd be keen to know :) – taifwa Apr 20 '17 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.