Why a Chroot? Because unlike other isolation mechanisms any Puppy can use it.
This started out as an exploration of running Wine in a Chroot, but evolved into a more general exploration of the Chroot mechanism. But you may want to skip this post and wait for someone to publish a more secure chroot system. s243a was working on that viewtopic.php?f=136&t=1917&i=1, especially with s243a’s sandbox script, viewtopic.php?p=17162#p17162. Something like it may overcome the ‘not-completely isolated OS flaw’ achieved via the currently available Chroot technique. Still, that technique goes a long way.
Running Windows Programs under Linux poses several privacy and security problems. The ones which this post attempts to deal with are the combined effect of (1) Wine’s lack of any anti-malware protection and (2) that it is generally intrusive into your Linux Operating System. Puppys’ counter-measure to these intrusions is isolation. EasyOS can run Wine in a containerized sub-ordinate operating system. Puli can run Wine from RAM, having loaded Wine into RAM from a now removed USB-Key. The following discusses a third approach, but first –in passing-- there may be a 4th.
Does anyone know what became of UnderDog? I’ve never used it. But as I recall at one time Puppys could run the applications under other operating systems with which they shared the computer. How does that differ from ‘Chrooting’ as described below?
In order to run Web-browsers which demand more recent glibc libraries that older Puppys could not provide, Watchdog and MikeWalsh developed a chrooted Web-browser, viewtopic.php?f=90&t=760. Dissecting it reveals two components: (1) a top level usr folder which will merge with the usr folder of the primary Puppy; and (2) a top level cont folder.
The following explains how to create an SFS with such /cont folder and the files in the MainOS's /usr folder to make use of the /cont folder. Start by creating a directory which --via the dir2sfs command-- will later be packaged as an SFS, referred to below as Chroot.SFS. Within it, create two folders: cont and usr.
As you know, Puppys are modular constructs, of which the puppy_verion_number.sfs contains the File -and-Window managers and the applications builtin by the Puppy’s Dev. For example, the puppy_xenialpup64-7.5.sfs provides that Puppy with jwm window manager, rox-filer, and all those applications you will find OOTB on the Start Menu, other applications which do not require menu entries, and “infra-structure” –the libraries and other files which tie all the pieces together and enable the Xenialpup64 operating system to make use of them.
Subject (I think) to the limitation that a 32-bit operating system can’t run a 64-bit operating system, any puppy_version_number.sfs can provide the contents of the /cont folder. Just mount the puppy_version_number.sfs and copy all its files and folders into /cont.
On the Screen-shot “Puppy-using-cont”, the top shows the cont folder as a Top-Level folder of the Main OS; the bottom shows the contents of the cont folder, to wit: an entire puppy_version_number.sfs having been unpacked into /cont.
- Puppy-using-cont.png (177.08 KiB) Viewed 2370 times
Reasons to run a Chrooted Puppy:
The original – overcomes the ‘only one glibc per operating system’ limitation.
Security – Under Puli, because of the way it handles SFS differently than Puppys, the Chroot.SFS can be smartloaded, or SFS-loaded after boot-up, and the partition on which the Chroot.SFS is located can then be unmounted. The Chrooted Operating System remains functional and those of its applications which worked before un-mounting continue to work.
Under Puppys, the partition from which the Chroot.SFS was mounted can NOT be unmounted. However, applications which run in the Chroot can not ‘see’ beyond the Chroot folder, apparently can not access any partition, including the one from which the SFS was loaded. and applications such as pmount fail. See Chroot-Mount-Unmount.png.
- Chroot-Mount-Unmount.png (272.19 KiB) Viewed 2370 times
But if a partition has been mounted using your MainOS, applications within the Chroot can access that partition.. For purposes of security, the Chroot.SFS can reside on a partition different from that of your Puppy. It can even be SFS-Loaded from a USB-Key’s partition, even one just big enough to only hold the Chroot.SFS. Under a Puppy running without a SaveFile/Folder --such as one in which setup using the NicOS-Utility-Suite Save2SFS module-- Puppy's Home/System partition is not automatically mounted and can remain unmounted throughout your entire work session.
Special Purpose Applications: Wine is obvious. But there may be others. For example, under Bionicpup the best, all inclusive, video editor is KDEnlive. But under Xenialpup it is Openshot. Running them both from the same OS is difficult-to-impossible as their python structures conflict.
Reason Not to Run a Chrooted Puppy.
Setting up the /cont folder can be a PITA. It’s not too bad if the application you want to run under it is a portable. Just drop the portable folder into the /cont/opt folder. Or a builtin – well, it’s builtin. But if its something else, you have to run the Puppy which will be used in /cont, install the pets, debs or what-have-you, test, and remaster that Puppy before its remastered puppy_version_number.sfs can be used in /cont.
Updating portable applications, or adding other portable applications –and you’ll be surprised at how many applications can work as portables-- isn’t too bad, either. Just mount the Chroot.sfs, copy its files into another folder, make the changes to /opt and dir2sfs that other folder. [Recommended, portables apps be tested before dir2sfs]. But if the application is not a portable, your only choice other than working your way to a remaster is to manually install each of the files required by an application and hope for the best. During that process there is no Puppy Package Manager and no form of dependency-checking.
And remember, if any bookmarks, plugins, addons, setting or configurations are necessary, that has to be done before the dir2sfs.. Configurations --such as those found in /root/.config-- have to be copied from their location in the Source-Puppy-booted-up into /cont/root/.config before running dir2sfs.
Applications in the Chroot can only access folders in the Chroot. The data files you download or create there will only be in RAM, generating all the problems which come about with RAM limitations. To preserve those files and/or work on them using an application of your Main-OS, you’ll have to move/copy them out of their folders in Chroot.
[A simplified version of MIkeWalsh's Spot2Root, https://drive.google.com/drive/folders/ ... 4vCp2rVBqX may be useful. Download, unpack, delete the unnecessary files/lines pertaining to changing permissions, keep those relating to moving files into/out-of folders, repack under a new name].
Before running dir2sfs on the folder with its populated /cont folder there are a couple of other things you have to do. (1) You have to know how to start the application within the Chroot and, possibly, (2) create the structure making it easy to do so from the MainOS; (3) create a connection between the chrooted application and your Main-OS; and create a Menu entry.
Applications are started by calling their binaries, or a bash-script or bash-wrapper “on the path”. Neither applications in /opt, nor by default, their scripts or wrappers are ‘on the path”. One location, unique to Puppys, is “on the path”: /root/my-applications/bin. That folder, within /cont, provides a convenient location to hold symbolic-links to and scripts or wrappers which call the binaries, or scripts or wrappers which already are a part of the application. Convenient: if you have to make adjustments all the relevant files will be in one place.
A simple example would be handling a Chrooted portable-firefox. Portable-firefox is started via a wrapper with the name ‘ff’. That wrapper is in the firefox folder, which would be in the /opt folder in /cont: /cont/opt/firefox/ff. You can open two rox windows: one to /cont/opt/firefox, the other to /cont/root/my-applications/bin. Drag the ff wrapper from the former into the latter and select Link(relative). You now have a symlink ‘on the path’ which will start the application.
I’ve attached a Temple containing example scripts for use in /cont/my-applications/bin. I’ll discuss them after explaining what you’ll need to do in the Chroot.SFS’s /usr folder. https://www.mediafire.com/file/2vzk3dzk ... ar.gz/file
Watchdog, MikeWalsh and s243a have actually made this part of the job pretty easy. As with all applications that are to have menu entries, each application within the Chroot that you intend to use from the Main-OS via a menu entry has three components: (1) a binary, script or symbolic link ‘on the path’; (2) an icon to display on the Menu-listing; and (3) a Desktop file which uses the previous two files.
The existing desktop file for an application can serve as a template for the same application that will be in the Chroot. But, you’ll probably want to change three or four things. First the name of the file so that it doesn’t overwrite the ‘non-Chroot’ version. For example, firefox.desktop can become Chroot-firefox.desktop. Chroot-firefox.desktop’s Name= argument undergoes a similar change, e.g. firefox can become chroot-firefox.
Third, and most important, the Exec= argument is edited to call the script which will call the file within the Chroot that starts the application within the Chroot.
Watchdog, MikeWalsh and s243a developed following Template for the script ‘on-the-path’ which is called by the Desktop’s Exec= argument. They located it at /usr/bin; and I’ve continued that arrangement. Only two things change from one Script to another. First, for obvious reasons, the name of each script must be unique. And Second, the name of the file within /cont which starts the application must also be unique AND that used within the Chroot to start the application. The following is the text within that script. Note, it continues the firefox example from above, where firefox is started by the symbolic link 'ff' in /cont/root/my-applications/bin to that file in /cont/opt/....:
#!/bin/sh
export LC_ALL=C
mount --bind /dev /cont/dev
mount --bind /proc /cont/proc
mount --bind /sys /cont/sys
mount -t devpts devpts /cont/dev/pts
cp /etc/resolv.conf /cont/etc/resolv.conf
cp /var/lib/dbus/machine-id /cont/var/lib/dbus/machine-id
xhost +
mkdir -p /cont/tmp/.X11-unix
mount --bind /tmp/.X11-unix /cont/tmp/.X11-unix
chroot /cont NAME-WITHIN-CONT-TO-START-APPLICATION "$@"
# for example: chroot /cont ff "$@"
exit
You may want to use a different icon than that used with the non-Chroot version: just makes it easier to spot on your Start-Menu. FWIW, I usually place icons in /usr/share/pixmaps. Using a consistent location for similar things avoids having to hunt or remember a bunch of exceptions.
It isn’t necessary to set up many applications in the Chroot to run via the Main-OS’s Menu; just those few you want to have quick access to. Within the Template are all the files required to initiate the Chrooted-OS’s rox file-manager. Note, however, that those files were customized to start the Chrooted-rox differently than if you just typed ‘rox’ in a terminal on the Main-OS. Per a post by s243a, before starting rox the following command is issued in the /cont/root/my-applications/bin/roxX script:
gdk-pixbuf-query-loaders –update-cache
Without that not all Chrooted-OS's rox windows will display icons: xenial's did; dpup-stretch's didn’t.
The Chrooted Rox is opened at the /cont/usr/share/applications folder. Many of the Chrooted-OS’s applications are then only a scroll and click away. Some applications, however, won’t function such as, fortunately, pmount as shown by the screenshot above.
If before dir2sfs you created two profiles for firefox-portable, you can create structures to open either from the menu. Or you can use the chrooted rox to file-browse into the chrooted /opt/firefox folder to start either via its wrapper. For that matter, you can create several chrooted-rox menu entries to open commonly used chrooted folders.
Both the bin/closechroot (without a menu entry) and bin/mscwchroot were part of the Watchdog/MikeWalsh build. I believe the former is necessary; and the latter –which starts the Chrooted Multiple-Sound-Card-Wizard-- may be in some instances.
Although the Chroot appears to be isolated, that may not be entirely true. pmount doesn’t work; but terminal applications within the Chroot do. At least in theory, a hacker may be able to ‘escape’ the Chroot. Moreover, if I read the arguments which are to be written to /usr/bin correctly –a BIG IF-- identifying characteristics of the Main-OS are written to the Chrooted-OS. Consequently, ‘finger-printing’ of your online activity continues to be possible. However, AFAICT, if you activate a VPN thru your Main-OS, web activity in the Chrooted-OS is channeled thru it.
