Mounts in chroot environment

[LIsLinuxIsSogood]

Hi, I need some help here with chroot. Please help me to figure out if there is some answer to the problem of the Mounts

inside my chroot environment, I have two concerns 1 about the actual chroot and users/groups, the other is about mounts and the use of sudo

Issue 1 (chroot user): chroot can only be accessed from the command line via user root (using linux32 chroot /path/to/chroot /bin/bash)...of course. That is working fine to enter chroot, so I can later use su -l user to switch users to get to regular user. (But see Issue 2 below about sudo as regular user once inside the chroot). The attempt to chroot as a regular user yields the following for an error....

[Hu]

chroot is a privileged system call, because clever use of chroot can confuse suid programs into doing things they should not. Theoretically, all such suid programs could be patched to check for dangerous environments before operating, but that would be time-consuming, so in practice, it is simply disallowed.

Your "workaround" with sshd works because sshd is privileged when it makes that call, and this is safe because only the system administrator can configure the chroot that sshd uses. As with many other things, the administrator could still use this insecurely, but if the administrator is competent and careful, it is safe.

Yes, sudo will not work properly when it is stored on a filesystem mounted nosuid. The option nosuid is specifically designed to prevent elevating programs, and sudo is designed specifically to be elevated. You should remove the nosuid flag on that filesystem, or refrain from using sudo (or su).

[LIsLinuxIsSogood]

I am pleased to see that my post made sense, at least now I will remember (as I do forget to read manuals on all these programs, which is usually true for most things I own as well...ha, since I don't own the software though because of GPL or MIT license or what not it would make sense that I become familiar through that method. Thanks for clearing the confusion at least I am aware that the problem is "expected" under the given scenarios. As for the bind mounts themselves and why they are all nosuid, so that I will probably want to review how the script works, which I copied and used directly from the gentoo wiki about 32-bit chroot...we will see I already modified them once. But could I be correct to assume that the order for mounting that with the suid bits is first make sure the operating system is mounted that way, and then (also) make sure that the chroot is mounted in that way as well?

[Hu]

That's one way to solve it. If you don't specify otherwise, the bind mounts will inherit the mount options of the underlying mount. You probably stored the whole chroot filesystem in a directory on a nosuid mount. You can fix that with appropriate bind mount / remount trickery.