Chroot: Is there a way to allow access to one external folder?

[mikeslr]

Forget it. The following is a bad idea, at least for me. See my next post.

Like a dog having found a new bone, I --having found goldendict, https://www.forum.puppylinux.com/viewto ... 426#p88426-- haven't been able to let it go without figuring out some way to run it under Slackos.

Of course, probably the easiest way for someone would be to compile it from scratch. But I don't compile. That would require learning the language of compiling: not likely even just the basics as goldendict uses several hundred libraries including Qt (or Qt5) and python. [If it isn't too obtuse, I can read bash scripts. But that's a far-cry from being able to think in code and intelligently write it].

Goldendict is available for ALL ubuntu-binary-compatible puppies; and I think those could be used in debian-binary-compatible puppys. pkgs.org indicates that a Void Linux version exists; as do versions for most 'Major Distros'. But AFAICT, there are no published Slackware builds; only instructions, https://slackbuilds.org/repository/15.0 ... oldendict/

An attempt to run any 'Ubuntu/debian' version under Slackos involves a long hunt for missing libs resulting in failure or (worse) a hung OS. I had more success building it as a portable within which are libraries made use of via an argument in the launch script establishing their path and usage (ala Battleshooter, fredx181, watchdog & MikeWalsh. That results in an application whose GUI appears; but is otherwise not functional. Via terminal 20 unresolved errors appear.

There's a version of GoldenDict for 32bit xenialpup. It would be simple to create a xenialpup32 bit Chroot which runs that GoldenDict that could be used under Slackos. The strength & problem with Chroots is that they ARE self-contained. GoldenDict is an application to display the contents of libraries/documents, and there are over 1.5 Gbs of those for it. You probably wouldn't want all. But if you left one out and later wanted to included it you would have to rebuild the Chroot.

IIRC, various version of EasyOS employed containers. While each was 'self-contained' all were able to write-to and (I think) read-from a specific external-to-the-container folder. So I wondered if a similar mechanism could be used with a Chroot.

Well, I figure I might be able to dissemble an EasyOS and find the relevant code. But a couple of hints might be helpful.

[mikeslr]

So I dissembled EasyOS-Buster and scanned how it works. To completely manage Containers, Barry K wrote 22 scripts. Guessing from there being a desktop file which called ec-chroot (one of the 22) that ec-chroot was the 'master script', I opened it in a text-editor. 470-odd lines of code, some of which lines providing explanatory notes. Early on in the notes is the comment " have patched kernel cap_sys_mount, split out from cap_sys_admin". Even if I understood the ramifications of cap_sys_mount and cap_sys_admin, I'm not going to learn how to patch a kernel just so that Slacko can run GoldenDict. Further on at line 250 the code starts the routine to 'mount namespaces' with further notes as to how the code overcomes obstacles. Currently, the mystery of 'namespaces' is 'above my pay-grade'.

The value of 'containers' is the security they provide. But 'the web is the mother of all malware' and Goldendict --once it and the 'libraries' you want have been downloaded-- has no reason to access the web. If desired, it can be run with wifi and/or ethernet disabled.

So, I wondered if the much simpler code developed by watchdog &all to manage an operating system in a Chroot might offer some clue as to how to 'escape' from the Chroot's self-containment. One of the scripts accompanying the original Chroot Mikewalsh published was that necessary for sound to be generated by applications within the Chroot, to wit: mscwchroot. Prominent among its code was the employment of the argument 'mount --bind'. Can 'mount --bind' be used to provide access to a specifically identified 'external' folder 'hanging' from /mnt in the primary OS? And no other? How would that folder be identified? This gets me back into an area with which I have an unresolved problem. The command blkid will identify all attached partitions by their unique UUID. But how to make use of the information it generates?

Well, the above gives me some areas to explore. But, if you know I'm venturing too close to a black-hole, please warn me.

[wiak]

Well, the above gives me some areas to explore. But, if you know I'm venturing too close to a black-hole, please warn me.

Because I habitually experiment, even on systems that I need to be safe and stable, I have on occasional completely scrubbed main system/partitions especially when using the likes of bind mount to bypass chroot-type environments, which effectively renders them far from being any kind of secure sandbox... Convenience is such a temptation, but so painful when the statistically inevitable does occur.
Really, a better and potentially just as convenient (if implemented well) approach is via network connections (even on same system) or some sort of carefully controlled interprocess communication mechanism IPC. I purposively published a version of KLA-XFCE including on iso cherrytree notes to allow users to easily understand and practice with industry standard container approach using 'podman', which to me is like a better 'docker' and command-compatible with that. I haven't also used that to implement good host access mechanisms but it would be a good small distro to work on that. Full podman support did not prove to be a large facility to include at all and being docker compatible has that great advantage of there being tons of docs on usage out there, and likely long term support and importance in modern computing practice. Being a system that is fully Arch linux compatible also makes it very efficient, reliable and easy to keep up-dated, with great package management and full KL-style frugal install flexibility. Yes, it is my own favorite, so I'm biased I suppose, but I do choose what I myself use most very carefully, and far from just for development purposes. For me, it was put together exactly because I wanted to learn current container theory and practice rather than any home-brewed chroot or simplified namespace mechanism.

[amigo]

'mount --bind' is probably what you want. Any chroot script is 'bound' to be using it mount /proc, /sys and /dev, etc. What it does is make a single directory or mount point visible in more than one place in the filesystem.

[mikeslr]

Thanks, amigo. My research also suggested that "mount --bind" was the method by which you can create a 'back-door' from the chrooted OS to the main OS.

And, Thanks, wiak for the warning. It wasn't the one I anticipated. Nor the one I encountered. There's probably a corollary to 'Murphy's Law': The thing you expect to go wrong and prepare for isn't the thing which will go wrong.

I decided to disregard wiak's sage advice. Well, maybe 'compelled to' is more appropriate than 'decided'. That there isn't a version of goldendict which can be used under Slackware/Slackos annoyed me. And that I had already formed an hypothesis as to how to create a Chroot meant that not testing it would have annoyed me even more.

I had figured out an easy way to probably overcome the 'identify the partition' hurdle. Despite the danger, If I located the folder to hold dictionaries at the root of my home partition, which shows up as sda3 when booting without a Save, the mount --bind argument would probably be either of these:

mount --bind /sda3/GoldenDict /cont/sda3/GoldenDict
mount --bind /mnt/home/GoldenDict /cont/mnt/home/GoldenDict

My thought was the I could include both; one of which would be superfluous but would do no harm.

To find out if that would expose the entire partition, in addition to the Chrooted GoldenDict, I created a Chrooted rox. If it could access folders on sda3 I'd scrape the project. [In my prior Chroot projects which did not mount-bind partitions the Chrooted rox was functional but could not 'escape' the Chroot].

None of my prior projects ran Chroots under Slackos. This one failed and when I ran the MainOS's script to establish the Chrooted rox or Goldendict, the terminal reported that a bind did not exist. Thinking I might have made some scribner's errror, I tried a Chrooted web-browser under S15Pup64 which I know works under 'Ubuntu' Pups. Same results.

There's something sufficiently different about Slackos that the recipe watchdog and MikeWalsh developed under 'Ubuntu' Pups, doesn't work.

Edit: Well, it doesn't work under 'Ubuntu's' either. My guess is that the two line above beginning mount --bind /sda3 and mount --bind /mnt/home-- won't create mount-points.

Well, for now I'm out of ideas which don't involve (a) learning the intricacies of Slackware and (b) learning how to compile. There are just many more pleasurable ways to spend my time than that.

[BarryK]

EasyOS use 'pflask', which is a kind of chroot on steroids. It also supports bind-mounting a folder to be visible inside the container, and in easy that is usually /files/shared

If all you want is Goldedict though, download Easy 5.3, it has Goldendict as a flatpak.

Easy 5.3 announcement:

viewtopic.php?t=8679

The only problem with flatpaks is they are big.

Goldendict will run as user "goldendict" and has write access in /home/goldendict and also in /files. Especially there is /files/apps/goldendict that you can save to and that folder is invisible to other appimage and flatpak apps, or any other app that runs non-root.

Edit:
Forgot, Goldendict is also available as an appimage. If you click on the "pkg" icon on the desktop, you can run either Appi the AppImage Installer, or Flapi the Flatpak Installer.
I recommend the flatpak, if you can tolerate the size.