I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how this could happen; I would think that PATH is set inside the chroot by the shell. How does PATH get set? I see how it is modified and have fixed my issue, provided I use a login shell.
On 08/30/17 15:16, Tony Nelson wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how
For a while now, /bin should be a link to /usr/bin. is /usr/bin in the PATH?
this could happen; I would think that PATH is set inside the chroot by the shell. How does PATH get set? I see how it is modified and have fixed my issue, provided I use a login shell.
On Thu, Aug 31, 2017 at 11:34 AM, Kevin Cummings cummings@kjchome.homeip.net wrote:
On 08/30/17 15:16, Tony Nelson wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how
For a while now, /bin should be a link to /usr/bin. is /usr/bin in the PATH?
On CentOS 5, /bin, /lib, /sbin aren't symlinks to their /usr counterparts; that was done with CentOS 7.
On 08/31/2017 08:34 AM, Kevin Cummings wrote:
On 08/30/17 15:16, Tony Nelson wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how
For a while now, /bin should be a link to /usr/bin. is /usr/bin in the PATH?
That's the most likely issue here. The OP keeps referring to an F20 box and IIRC that predates the /bin<-->/usr/bin changeover.
To answer the question, bash has an initial PATH compiled into it. What that PATH contains depends on how bash was built and how bash was launched (they inherit the environment of the launching process-- interactive or not). The vast majority of systems bugger that default path by use of the /etc/bashrc script and possibly custom scripts in /etc/profile.d.
Interactive (login) shells are typically launched by the login process and inherit the login process' PATH (see "man login" for details). The additional stuff (/etc/bashrc, /etc/profile, etc.) are also invoked.
A chrooted shell gets its environment from the chroot process and would run any normal startup scripts, but they'd be from the chrooted /etc, not necessarily the root system's /etc.
this could happen; I would think that PATH is set inside the chroot by the shell. How does PATH get set? I see how it is modified and have fixed my issue, provided I use a login shell.
---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Veni, Vidi, VISA: I came, I saw, I did a little shopping. - ----------------------------------------------------------------------
On 08/31/2017 09:26 AM, Rick Stevens wrote:
On 08/31/2017 08:34 AM, Kevin Cummings wrote:
On 08/30/17 15:16, Tony Nelson wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how
For a while now, /bin should be a link to /usr/bin. is /usr/bin in the PATH?
That's the most likely issue here. The OP keeps referring to an F20 box and IIRC that predates the /bin<-->/usr/bin changeover.
To answer the question, bash has an initial PATH compiled into it. What that PATH contains depends on how bash was built and how bash was launched (they inherit the environment of the launching process-- interactive or not). The vast majority of systems bugger that default path by use of the /etc/bashrc script and possibly custom scripts in /etc/profile.d.
Interactive (login) shells are typically launched by the login process and inherit the login process' PATH (see "man login" for details). The additional stuff (/etc/bashrc, /etc/profile, etc.) are also invoked.
A chrooted shell gets its environment from the chroot process and would run any normal startup scripts, but they'd be from the chrooted /etc, not necessarily the root system's /etc.
How about using "env": env PATH="new_path" chroot /some_dir
Wouldn't this preempt the passed PATH, profile, bashrc, and the dot files? If so, chroot could be defined as an alias to "env ... chroot" and thereby eliminate the problem.
this could happen; I would think that PATH is set inside the chroot by the shell. How does PATH get set? I see how it is modified and have fixed my issue, provided I use a login shell.
On 08/31/2017 09:41 AM, Mike Wright wrote:
On 08/31/2017 09:26 AM, Rick Stevens wrote:
On 08/31/2017 08:34 AM, Kevin Cummings wrote:
On 08/30/17 15:16, Tony Nelson wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how
For a while now, /bin should be a link to /usr/bin. is /usr/bin in the PATH?
That's the most likely issue here. The OP keeps referring to an F20 box and IIRC that predates the /bin<-->/usr/bin changeover.
To answer the question, bash has an initial PATH compiled into it. What that PATH contains depends on how bash was built and how bash was launched (they inherit the environment of the launching process-- interactive or not). The vast majority of systems bugger that default path by use of the /etc/bashrc script and possibly custom scripts in /etc/profile.d.
Interactive (login) shells are typically launched by the login process and inherit the login process' PATH (see "man login" for details). The additional stuff (/etc/bashrc, /etc/profile, etc.) are also invoked.
A chrooted shell gets its environment from the chroot process and would run any normal startup scripts, but they'd be from the chrooted /etc, not necessarily the root system's /etc.
How about using "env": env PATH="new_path" chroot /some_dir
Wouldn't this preempt the passed PATH, profile, bashrc, and the dot files? If so, chroot could be defined as an alias to "env ... chroot" and thereby eliminate the problem.
I suppose you could:
env PATH="/bin:/sbin:/usr/bin:/usr/sbin" chroot /some_dir
Remember that the chrooted shell would be looking for the directories in the "PATH=" under "/some_dir", since the shell would rooted there.
Chroot jails can be complex to set up. You need all the utilities you need in the chroot along with their required libraries, etc., etc. It might be better to look at things like sandboxes (based on selinux), lxc (linux containers) or firejail (based on linux namespaces and other goodies).
Oh, wow, my brain is starting to cramp on this. :p ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Admitting you have a problem is the first step toward getting - - medicated for it. -- Jim Evarts (http://www.TopFive.com) - ----------------------------------------------------------------------
On 17-08-31 12:41:09, Mike Wright wrote:
How about using "env": env PATH="new_path" chroot /some_dir
Wouldn't this preempt the passed PATH, profile, bashrc, and the dot files? If so, chroot could be defined as an alias to "env ... chroot" and thereby eliminate the problem.
Seems to work. Note that this only changes the passed path; any pathmunge()'ing in the chroot's startup scripts still happens. I've already fixed the problem inside the chroot, but I'll set this up if I find another problematic chroot. It should be OK to look at /usr/bin twice if /bin -> /usr/bin and the command doesn't exist.
On 08/31/2017 11:14 AM, Tony Nelson wrote:
On 17-08-31 12:41:09, Mike Wright wrote:
How about using "env": env PATH="new_path" chroot /some_dir
Wouldn't this preempt the passed PATH, profile, bashrc, and the dot files? If so, chroot could be defined as an alias to "env ... chroot" and thereby eliminate the problem.
Seems to work. Note that this only changes the passed path; any pathmunge()'ing in the chroot's startup scripts still happens. I've already fixed the problem inside the chroot, but I'll set this up if I find another problematic chroot. It should be OK to look at /usr/bin twice if /bin -> /usr/bin and the command doesn't exist.
If the pathmunging is done in a "/<wherever-chroot-is>/etc/..." script or in a "~/.whatever", absolutely as that is done after the chroot spawns the shell in the chrooted environment. If you're saying it happens before the chroot, then I don't know how that'd occur.
I think the issue you've been having is that your chroot environment doesn't have the merged /bin and /usr/bin. It has separate /bin and /usr/bin directories. After the merge of /bin and /usr/bin was established, I believe bash's built-in default PATH was modified to assume this symlink was done. That's why the new bash doesn't have a separate "/bin" in its default path. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - If you can't beat your computer at chess...try kickboxing! - ----------------------------------------------------------------------
On 17-08-31 14:43:10, Rick Stevens wrote:
On 08/31/2017 11:14 AM, Tony Nelson wrote:
On 17-08-31 12:41:09, Mike Wright wrote:
How about using "env": env PATH="new_path" chroot /some_dir
Wouldn't this preempt the passed PATH, profile, bashrc, and the dot files? If so, chroot could be defined as an alias to "env ...
chroot"
and thereby eliminate the problem.
Seems to work. Note that this only changes the passed path; any pathmunge()'ing in the chroot's startup scripts still happens. I've already fixed the problem inside the chroot, but I'll set this up if I find another problematic chroot. It should be OK to look at /usr/bin twice if /bin -> /usr/bin and the command doesn't exist.
If the pathmunging is done in a "/<wherever-chroot-is>/etc/..." script or in a "~/.whatever", absolutely as that is done after the chroot spawns the shell in the chrooted environment. If you're saying it happens before the chroot, then I don't know how that'd occur.
No, I didn't say that. I said "I've already fixed the problem inside the chroot".
I think the issue you've been having is that your chroot environment doesn't have the merged /bin and /usr/bin. It has separate /bin and /usr/bin directories. After the merge of /bin and /usr/bin was established, I believe bash's built-in default PATH was modified to assume this symlink was done. That's why the new bash doesn't have a separate "/bin" in its default path.
bash's default path is not being used; if it were, it would be the CentOS5 bash. PATH is set in the chroot environment by chroot itself, which is how the outer PATH or the env PATH get into it. The f20 chroot works because it postdates the /bin -> /usr/bin merge and doesn't need /bin in PATH. CentOS5 has separate /bin and /usr/bin, and needs /bin in PATH. That can be passed in, as with env, or done in the chroot by pathmunge'ing in a bash startup script in /etc/profile.d (both /etc/profile and /etc/bashrc source that directory).
On 17-08-31 11:34:21, Kevin Cummings wrote:
On 08/30/17 15:16, Tony Nelson wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how
For a while now, /bin should be a link to /usr/bin. is /usr/bin in the PATH?
CentOS5.
It is still a mystery how it worked on f20, as it postdates the /bin -> /usr/bin merge and its PATH does not contain /bin.
On Wed, Aug 30, 2017 at 3:16 PM, Tony Nelson tonynelson@georgeanelson.com wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how this could happen; I would think that PATH is set inside the chroot by the shell. How does PATH get set? I see how it is modified and have fixed my issue, provided I use a login shell.
It's because chroot keeps PATH set. So if your pre-chroot PATH doesn't include "/sbin" or "/bin", they won't be in the chrooted PATH:
root@fedraw ~ # echo $PATH /usr/sbin:/usr/bin
root@fedraw ~ # chroot /bb ./busybox sh
\u@\h \w # echo $PATH /usr/sbin:/usr/bin
\u@\h \w # exit
root@fedraw ~ # PATH=/sbin:/bin:/usr/sbin:/usr/bin chroot /bb ./busybox sh
\u@\h \w # echo $PATH /sbin:/bin:/usr/sbin:/usr/bin
\u@\h \w # exit
root@fedraw ~ #
If you use a login shell (eg, "chroot /bb bash -l" instead of "chroot /bb bash"), the dotfiles that will be sourced will set the appropriate chrooted PATH.
On 17-08-31 12:18:38, Tom H wrote:
On Wed, Aug 30, 2017 at 3:16 PM, Tony Nelson tonynelson@georgeanelson.com wrote:
I have an old CentOS5 that I chroot into. On my old f20 box, PATH included /bin, but now on f26 it does not. I don't understand how this could happen; I would think that PATH is set inside the chroot by the shell. How does PATH get set? I see how it is modified and have fixed my issue, provided I use a login shell.
It's because chroot keeps PATH set. So if your pre-chroot PATH doesn't include "/sbin" or "/bin", they won't be in the chrooted PATH:
OK, now I get it. I have another chroot for f20, which is after the /bin -> /usr/bin transition, that works because it doesn't need any help.
...
If you use a login shell (eg, "chroot /bb bash -l" instead of "chroot /bb bash"), the dotfiles that will be sourced will set the appropriate chrooted PATH.
Sadly, no, not without editing them. The only pathmunge()'ing I see is for root's use of sbin. I added a file to /etc/profile.d to pathmunge /bin, which sets the path for both interactive and login shells.
I still have an issue of no saved history on plain interactive shells, so I do specify a login shell. My f20 chroot doesn't have the problem, either as a login shell or not as shown by `shopt login_shell`, but it's a more complicated (overlayfs over ro mount) setup, as well as newer than the CentOS5 setup.
The history issue with CentOS5 chroot is new with f26, and worked in f20.
-
Kevin Cummings -
Mike Wright -
Rick Stevens -
Tom H -
Tony Nelson