Puppy Linux Discussion Forum

This seems to be the logical place to post about an exploration.
A post today, viewtopic.php?p=21374#p21374 got me thinking about the possibility of running wine in a chroot. Watchdog & Mike Walsh's endeavors have resulted in a number of chrooted applications including Chrooted Iron 88 'portable' as a standalone SFS for older Puppies, viewtopic.php?f=90&t=760 with "Xenialpup 7.5 as the 'chrooted environment'".
Mounting that application reveals that it consists of two parts: (1) the aforementioned Xenialpup 7.5 within a top level folder named 'cont'; and (2) files in /usr to initiate the chroot and to provide menu entries from one's main operating system to the applications in the chroot. Although many of the original Xenialpup's files/applications were removed from the chrooted Xenialpup, not all of them were and some which remained might still function. I had previously discovered that one which did was /cont/usr/uget: handy if you need to download a large file.
As 'fuse' --it might be something else-- does not function, neither AppImages nor SFSes can be used by the chroot OS. My initial idea of running portable-wine from /cont/opt did not work. So I switched my attention to the possibility of installing a wine pet. I SFS-loaded the Iron-Chroot, ran Iron to make certain the chroot was functioning, and [using rox under my main OS] copied one of version2013's wine pets, wine-5.22_v3.2. pet into /cont/root. [I later tried this with wine-4.3_v3.1.pet with the same results].
[As this was for exploration purposes, creation of the /usr files and folders --the (2) above-- could wait].
/cont/usr/xterm also functions as I discovered by file-browsing to it, and left-clicking it. With that xterm running I cd'd into /root and then entered the command /cont/usr/local/petget/petget wine-5.22_v3.2. pet.

Wine was dutifully written/installed. But, of course, that installation is useless until you create a wine environment. So I entered the command wine wine.cfg. It ran but hung when it tried to download mono. After killing that instance of xterm, however, by opening another instance of xterm and typing the command wine winefile wine file-manager dutifully appeared.
By the way, I don't have any other instance of wine on my OS. I do have portable-wine. But applications run under it do not respond to the command wine. To invoke programs under portable-wine the command wine.sh is required.

With wine installed portable applications such as Netsurf and Atlantis Wordprocessor Lite could be started merely by (left) Clicking their respective exes.

I had copied their folder into /cont/opt. Netsurf ran, enabled me to open to this Forum, but not log in. Portable radiosure ran and played selected radio stations.

But opening pfind via a terminal started at /cont, selecting Search Director and making certain that Search Sub-directories was checked, neither the search term “wine” nor “.wine” revealed any relevant files. [The pet used to install it was found, along other files/folders with wine in their names, e.g. qwine.png and references to wine under quickpet]. Thinking that wine may have escaped the chroot, I ran pfind from /. Same results. Usually installation of a wine pet creates a hidden (.wine) directory under /root. But visual examination of /root and /cont/root also revealed nothing. Neither did other possible locations such as /cont/usr and /usr.

Where can the missing Chroot-Wine be?

The answer may not be important if where-ever it is survives unloading the Iron-Chroot SFS. If it survives that, a menu entry can be created in the main OS: As I mentioned, portables in /cont/opt could be started merely be clicking their executables. So, for example a bash script should be able to start a window's application in /cont/opt. Still, it is rather curious. Unloading the Iron-Chroot.sfs may reveal what was written to the /cont folder during this exploration.

I'll unload the Iron-Chroot.sfs and see what happens.

Duh. I forgot my oft posted advice: When exploring matters which can muck-up a perfectly running system first backup your SaveFile. SFS(un)load won't let me do that on the fly. I can chose to re-boot without Saving which will wipe whatever I have in RAM, and thus the files and folders created during the exploration discussed in the above post. Or I can Save and be stuck with it in the hope that on reboot I can unload. Or --and I think this is the best way to proceed-- I can start from scratch.
Reboot without Saving.
Create a backup SaveFile.
Then SFS load the Iron-chroot.sfs. Install Wine. Test it. Save. Change the name of the Iron-chroot.sfs so that it can't be loaded on bootup. And see what remains in the /cont folder.
Something to keep me busy tomorrow.

As the title says, Chrooted Wine -- Appears to violate chroot

Duh2. Ran the experiment using bionicpup64 frugally located on my hard drive. My hard-drive also holds several other Puppies, some using SaveFolders; my "Vault" in which I've stored many applications including those bearing the name wine, and a couple of versions of portable-wine. So running pfind "All files" with the search term "wine" generates a list having scores of hits. However, as far as I can tell, even though the wine pet was in the chroot and I used the chrooted version of petget to install it, it wrote files to /usr in the main OS thus escaping the chroot.

After booting with the Iron_Wine-Chroot.sfs removed --so that it could not be sfs-loaded-- the /cont folder -as expected-- remained including the /cont/opt/Atlantis folder. You may recall that I ran Atlantis from /cont/opt. Well it got there because I had copied its folder from /mnt/home/xp-apps. I wondered were it stored documents. It stored them where the original had been configured to store documents: /mnt/home/my-stuff/documents.

Nothing in the /cont folder suggested the existence of wine. And opening a terminal and entering the command "wine /cont/opt/Atlantis/awp.exe" did not start Atlantis. But left-clicking it did. But you'll remember I have portable wine on the system. However, entering the command wine winefile opened wine's file-manager. So even though broken, it must exist somewhere. Hence, the need to continue to hunt for where.

The Bionic64 I used has undergone many changes. So I can't be sure the files relating to wine pfind found (and I visually confirmed) in /usr --or was it /usr/??something??-- were written by the above experiment.

Best to try this from an OS on a USB. And to double-check my previous finding that iron and other web-browsers in a chroot could not access the main OS.

@mikeslr :-

Couple of points:-

As 'fuse' --it might be something else-- does not function, neither AppImages nor SFSes can be used by the chroot OS.

Mmm.....not entirely true.

I run two Xenialpup 'chroots'. Xenialpup 7.5 for 32-bit Pups, and Xenialpup64 for one or two 64-bit Pups. I've never bothered trying to load SFSs in either. However; curiously - and this IS curious - where the 2-series Openshot AppImages won't run under Xenialpup64 on 'bare metal', they WILL run in the chrooted Xenialpup64 within Quirky64 'April' 7.0.1 (my 'daily driver').

I've tried this with several of the recent 2-series releases - 2.34, 2.43, 2.50 AND 2.51 - and without exception, they run & function correctly.

(You know as well as I do this is true; we tried these AppImages under Xenial64 AND Bionic64.....and, without exception, they won't run. If I try to run 'em in Xenial64 natively, 'X' crashes and I have to restart it again.)

In fact, I run several AppImages from the chroot under Quirky.....including Flameshot, LosslessCut, MuseScore, Peek & Scribus.

------------------------------------

I, too, tried installing WINE in the chroot. Try as I may, I cannot get it to function.....

Mike.

Concluding this exploration. First the good new. Answering my concern: "And to double-check my previous finding that iron and other web-browsers in a chroot could not access the main OS":

Linux Web-browsers included in the Chroot are safely limited to the Chroot. Chrooted Iron doesn't see either files-under /mnt and (mnt) being a symlink to /initrd) doesn't even have a
listing for init. They can't download out of chroot.
Iron, being a 'Chromium-Clone', doesn't have a module for opening files on your system. [Edit: later discovered Ctrl-o will open files; but subject to the same limitation as Seamonkey]. Seamonkey does. But a Chrooted Seamonkey could not access anything outside of the Chroot, not even if a symlink to an 'external-file' was intentionally placed within the Chroot.

Now the bad news. Even though the wine pet had been placed within the Chroot, and the Chrooted petget used to install it, Wine wrote its files to the Main OS.
Desktops had been written to /root/.local/share/applications. Mime types to /root/.local/share mime/applications. /usr/bin/contained executables and /usr/lib32 contained various dlls, exes and other wine-related files. Other wine-relevant files were in /usr/local, /usr/sbin and /usr/share.
Running Atlantis's setupfile, even though its intended place of location was to be /cont/opt, the installation saw everything.

And when installation was complete, IIRC, its default folder for saving documents was in /root.
My best guess is that, wherever the wine installation file is located, it begins it installation at /. Perhaps it could be compiled to do otherwise.
But until then the best advice I can provide for using Wine is to treat it as an unsafe framework:
(1) Only download Window programs from trusted sources, when possible employing VPNs or secure web-browser with addons to foil 'man-in-the-middle' infringments\.
(2) Do not use Window programs which access the internet, at all.
(3) Employ the technique used by trister, viewtopic.php?p=19648#p19648 to start your Windows program. TBH, I'll have to experiment with this to fully understand it.
But see my post here, viewtopic.php?p=21774#p21774

@mikeslr :-

The sym-link trick DOES work, Mike.....if you do it the right way round.

You CANNOT sym-link an external directory/file/whatever INTO the chroot. You CAN, however, do it the other way round....

I have a directory @ /cont/root/MEDIA in each of my chrooted Puppies. This contains sym-linked Download/Upload directories from within the chroot.....and I then sym-link the /cont/root/MEDIA directory into the "host" Puppy's /root 'user' directory. This is how I get stuff in & out of the chroot....

Mike.

Hi Mike,

Perhaps I should have explained that the experiment was to see whether the chrooted-Seamonkey could open a file in the Host system by following a symbolic link to it in the Chroot created by the Host system.

Intentionally getting things in and out of the Chroot from the Main OS isn't a problem. For convenience I just Bookmarked a folder /cont/root/cDownloads in the Main OS: 'c' to Downloads included so that I could tell at a glance that it wasn't /root/Downloads of the Main OS. What I was particularly concerned about was whether some hacker or downloaded malware, using resources only available to the chrooted operating system could 'escape'.

mikeslr wrote: ↑Sat Apr 03, 2021 11:09 pm

Hi Mike,

Perhaps I should have explained that the experiment was to see whether the chrooted-Seamonkey could open a file in the Host system by following a symbolic link to it in the Chroot created by the Host system.

Intentionally getting things in and out of the Chroot from the Main OS isn't a problem. For convenience I just Bookmarked a folder /cont/root/cDownloads in the Main OS: 'c' to Downloads included so that I could tell at a glance that it wasn't /root/Downloads of the Main OS. What I was particularly concerned about was whether some hacker or downloaded malware, using resources only available to the chrooted operating system could 'escape'.

@mikeslr :-

I have tried this myself, Mike. For me, at least, I found there is no way that anything inside the chroot can access anything outside of it. Unless, of course, I wasn't trying hard enough.....but then, I don't have a 'hacker' mind-set, and there's no pot of gold BIG enough to persuade me to expend that much mental energy!

Your point is well-taken, though, especially since it would seem that slowly, more & more Puppians are beginning to try this chroot stuff out for themselves.

Mike.