Mkchroot Script Update to work across various RHEL Systems

[Luis I. <lui...@ya...>]

Mkchroot update for 32/64-bit RHEL Systems support by Luis Iafigliola.
Dated 29th June 2010.

As such the CHROOT script will configure the Jail with the following runtime parameters:

./mkchroot.sh <Jail Directory> <CHROOT User> <CHROOT Jail Directory Permissions> <CHROOT Group>

For example:

./mkchroot.sh /var/www/html/websites webuser 2775 webgroup

The sequential changes (as presented in the CHROOT script) include:

1) Specifying the GROUP parameter.
   I added this in order to have a common group in which all RSSH users will reside.
   The idea behind this is that the control of filesystem access is achieved at the group level.
   From the permissions parameter above, you can see that the group has WRITE access.
   This allows the CHROOT group to have common access to the relevant set of files (more on this in 
   Step 3 below).

2) Detection of whether it is being run on an x86 64-bit system.
   This will then pinpoint the location of the libraries directory on the filesystem.

3) Setting the GROUP parameter when the script is being run only as the root user.
   I set an SGID, as any files created within the Jail by the CHROOT User should be owned by this common 
   group for shared access.

4) I believe in RHEL5 32-bit at least, that the shared libraries output may contain an "0x" value.
   This breaks the copy of dependent libraries required by the specified binaries in the Jail.
   There is a flag which has been set to capture the "0x" value and bypass it.
   I believe I ran into this bit of code somewhere on the net, so kudos to the original author.

5) Particular libraries which are required for proper dependency resolution.
   Once again I ran into these somewhere on the net, so my thanks go out to the original author.

6) Slight change to copy the CHROOT User into the Jail passwd file, rather than the whole file itself.
   The same goes for the CHROOT group.

7) Set the relevant CHROOT directories within the Jail to be executable to all and not readable.
   I prefered the approach where the CHROOT User did not need to concern themselves with the contents
   of these directories.

NOTE. A catch with Item 7 is that the CHROOT User should first create the relevant directory structure
      required in the Jail. If the CHROOT User happens to view a CHROOT directory within an SFTP 
      session, they will not be allowed. If they then try to refresh the directory listing, the session 
      does not recover. So it is more of a gotcha rather than a bug when setting the CHROOT directories 
      in the Jail as executable only (as per my reasoning in Step 7). The workaround requires that the 
      CHROOT User proceeds to create their intended directory structure. Thereafter if attempting to 
      access the CHROOT directories, they should as their last action attempt to access their created 
      directory structure. Any refresh will then be allowed and not break the SFTP session. Otherwise as 
      an alternative, the CHROOT script can be changed to NOT set these CHROOT directories to read-only 
      for group and others. This is explained as further comment within the code.

Finally the CHROOT script has been configured to allow SCP, SFTP and RSYNC for the relevant Jail.
Ideally you should only really need RSYNC for automated copies with mirroring or SFTP if a manual approach is required.