SOLVED - Removing chroot jail

[askquestiongetanswernobs]

I discovered that on a new server that PHP is in "chroot jail". I tested the command stat -c %i / and according to one website I was found while doing some research discovered that the programming language was indeed in "chroot jail" (it returned a 2). The core problem was that I could not access /etc/os-release via PHP shell_exec() and checked whoiam for the Linux/PHP user, checked the file permissions, checked the file manually in the FTP and PuTTY/terminal, etc and there was absolutely no other explanation other than "chroot jail".

I would like to continue to use the "chroot jail" only if I can use the Linux root user to allow the programming language access to specific files. No, PHP is run under a different user, not root. No: I do not want to blindly grant access to entire directories because then the point of it becomes null and void. In example I need PHP to have access to the /etc/os-release file, not a copy of it. If the original is updated the copy isn't and that negates the point of access. I do not want to grant access to literally all of /etc/. If granting individual file access is possible I would then like to know:

• I have not been able to find a list of chroot commands with basic descriptions.
• I want to know how to list an index of all chroot jails and their respective users to avoid repeat the "discovery" of them.
• I want to know how to list the "walls" of each "chroot jail" e.g. what files/directories they have access to.
• I want to know how to grant read access to a file like the /etc/os-release file (read as in just read, not write or execute).
• For contrast to the read option, I want to know how to grant write access to a file.
• Chroot only matters as long as I can extend access to specific files and not a copy of the file that does not get updated when the original is updated.

If I can not grant chroot access to direct files (not copies of them) then, by using the Linux root user I need to know how to bust PHP out of the "chroot jail".

So either: how do I extend the "chroot jail" to allow access to read only specific files (not entire directories and not merely copies of those files) or if that is not possible how do I properly dismantle the "chroot jail" without causing damage to the file system?

For any answers please do not presume or infer that I know the involved syntax as that is a large part of my question. I reference absolute paths instead of relative paths for example. Thank you.

* Edit 1: I found a command that lists "chroot jails" however since PHP is not always running the caveat is that I have to have PHP do something to run long enough for the command to see it running. So it's not a proper chroot index function. It is possible with a basic script:
<?php
echo 1;
sleep(30);
echo 2;
?>

So then running the command in the terminal as root:

for file in `find /proc/ -type l -name "root" -print 2> /dev/null | grep -Eiv /task/ 2> /dev/null`; do PID=`ls -d $file 2> /dev/null| awk -F "/" '{print $3}'` && printf "%s = %s = %s\n" "$PID" `ps -p "$PID" 2> /dev/null | tail -n1 | awk '{print $4}'` `readlink $file 2> /dev/null` | grep -Eiv "(= /$|^\s*=\s*$|^.*?=\s*$)";done

...resulted in listing several processes including:

4***** = php-cgi = /usr/share/cagefs-skeleton

So yes, I've got a better confirmation that PHP is stuck in "chroot jail". I'm now working to verify if adding a file is 1. possible and 2. updating the actual file results in the "copy" being updated or not.

 

[askquestiongetanswernobs]

WHM --> Plugins --> cagefs, remove the Linux user and commit the update to cagefs.

Reloaded the page and PHP could suddenly see the files in the file system that only it could not see.

A function must have index, create, edit and delete functionality that is reasonably easy to use and reasonably documented or it should not even exist! All chroot's functionality in the terminal included was the ability to create additional messes.

 

[Trenix25]

The idea of a chroot jail is to keep everything isolated to that directory tree. If you want other files to be accessible while "in jail" you will need to copy them into it on your own. I use an anonymous FTP server and have my own /bin and /etc directories in that space. Be sure to set the correct file ownership information. It is generally recommended to have the files owned by someone who cannot modify them while "in jail" unless you want them to be able to do so.

Signed,

Matthew Campbell

 

[askquestiongetanswernobs]

The idea of a chroot jail is to keep everything isolated to that directory tree. If you want other files to be accessible while "in jail" you will need to copy them into it on your own. I use an anonymous FTP server and have my own /bin and /etc directories in that space. Be sure to set the correct file ownership information. It is generally recommended to have the files owned by someone who cannot modify them while "in jail" unless you want them to be able to do so.

Signed,

Matthew Campbell

Hi Matthew. No, I actually like the idea of chroot jail however it's implementation was wildly botched.

When I implement something there are five critical aspects that have to be done for a feature to be considered ready for the public: index, create, update, search and delete. If I can't get an index (list) of something then I'm blind. If I can't update then I have to be extra careful when I create. If I can't delete then I'm at the mercy of whatever is stuck in the system. The chroot command only allows creating, nothing else and that is the problem. If someone can't do something competently then just don't do it in the first place.

So chroot jail is a good idea though was implemented in the laziest way possible. So the implementation should be removed though someone (maybe a future employee of mine) will one day get paid to properly implement the concept.

 

[Trenix25]

Hi Matthew. No, I actually like the idea of chroot jail however it's implementation was wildly botched.

When I implement something there are five critical aspects that have to be done for a feature to be considered ready for the public: index, create, update, search and delete. If I can't get an index (list) of something then I'm blind. If I can't update then I have to be extra careful when I create. If I can't delete then I'm at the mercy of whatever is stuck in the system. The chroot command only allows creating, nothing else and that is the problem. If someone can't do something competently then just don't do it in the first place.

So chroot jail is a good idea though was implemented in the laziest way possible. So the implementation should be removed though someone (maybe a future employee of mine) will one day get paid to properly implement the concept.

For chroot(2) to work you will either need to be root or use the cap_sys_chroot permission/capability. If you're doing it in PHP rather than C then you'll need to deal with whatever that offers. It sounds like you'll need at least rw for files and rwx for directories. Another thing you might consider is using a named pipe (fifo) file to ask another running program to perform these operations for you. It can check the request to make sure it meets the correct security requirements. The idea of chroot is to make sure no one can escape your little server world to access other space on the system that hosts the server.

Signed,

Matthew Campbell