Issues with openssh ebuild restarting sshd inside chroot

[kloepfer]

Background: On my server system, I created several chroot'd areas that I use to build Gentoo packages for other systems I maintain that use different make.conf parameters (yes, I share my distfiles cache to lessen the load on the upstream servers).

Issue: Because the net-misc/openssh ebuild now restarts openssh through rc-service, rc-service sees sshd outside the chroot environment, kills sshd in the server environment, and starts the sshd inside the chroot build environment. I understand the reason for doing this (Gentoo bug 709748), but the method in the ebuild has caused unintended consequences for me. I am also concerned about this being done in other ebuilds in the future (currently this only happens automatically for openssh).

Discussion: Right now, I handle this by stopping sshd on the server before updating the build inside the chroot environment. Looking at the ebuild, it looks like setting ROOT to "/" in my chroot build environment may resolve this, but I was wondering if anyone could suggest a better solution for hiding the process list from rc-service inside that chroot area to prevent this from being a problem in the future.

I considered reporting this as a bug (is the bug openssh or openrc?), but I wanted to throw this out to the forum before I approached it from that direction.

I realize that my build process could be done differently by treating the other build environments like a cross-compile, and setting ROOT to those areas, but I don't like this approach because a mistake could easily damage the server environment, and I also have a nice workflow doing this with chroot and some scripts. My other thought would be to create lxc containers rather than chroot environments, but that's a lot more complicated to maintain and comes with its own set of challenges.

Thanks in advance for any feedback on this.

[Administrator edit: fixed [bug] tag. When the target is the tag's text, the tag should not use =. -Hu]

[pingtoo]

Welcome to Gentoo

So, what is you want to discuss? change openssh ebuild behavior?
Or prevent chroot environment kill openssh outside?
Found a way to work the chroot from remote?

I don't see how it is a bug, It is design by Gentoo openssh maintainer. it just does not work your way. Doing chroot then world rebuild I would think it is not common, therefor it does not fall in to openssh ebuild covered use case.

Have you consider setup your chroot with unshare --pid, so the process namespace is separated from outside?

[szatox]

[kloepfer]

[kloepfer]

[pingtoo]

That is the reason I ask about namespace and/or use unshare.

because most of us it is not intuitively (common sense) think bind mount what does it mean what is doing for our host environment.

I know originally the chroot concept was do bind mound proc, sys and dev than it progress to everything else. but that was done without thinking. I am pretty sure it was learn that just bind mind is not right, then it develop to use make-salve and realize it is still not right so it come up with arch-chroot.

All in all is you must understand chroot, is not isolation. it just simply for the "session" the use call chroot, It is complete different mean for then entire host.

[szatox]

Yeah, I though sharing /run would have explained this abnormal behavior. I'm glad the hint worked and you figured it out.

You don't have to fully replicate your host's mounts inside your chroot, you only need to provide things which are necessary for the task at hand. My "maintenance set" of mountpoints is /proc /sys /dev /dev/pts. It is enough for running an administrator's interactive session and it keeps emerge from complaining... And since those are kernel interfaces, it doesn't matter whether thay are mounted with --bind or not.
Anyway, adding anything to a chroot should always be a deliberate decision, since it essentially makes cracks in the wall, and when you have a crack, things might leak.
_________________
Make Computing Fun Again