Thanks for the discussion Mohammad :-)

Yeah, I completely agree. LFS is a good approach and with proper fine-tuning, it could become minimal and robust.

I think, with this approach, this is what you have in mind:

• build the basic structure required for LFS without root privileges and capabilities
• restricting filesystem access of the rest of the project scripts to the project directory using a user namespace and a nice chroot which uses the built LFS.

unshare -U -r bash

chroot "$LFS" <LFS_ROOT>/bin/env -i HOME=<LFS_ROOT> TERM="$TERM" PS1='\u:\w\$ ' PATH=<LFS_PATH_VAR> <LFS_ROOT>/bin/bash --login +h

• and from now on the rest of the project script is run inside this chroot environment without filesystem access to anything outside the project directory.

Please correct me if I have assumed anything not inline with the existing plan.

---

P.S. As someone with tendency towards a theoretical mindset and
being always in awe of self-consistent constructs ;-), if I wanted to perfect this approach, I would have slightly modified the first step:

• I would have tried to build the LFS itself inside a minimal chroot'd environment composed of the minimal things that you would need from the existing host OS to build that nice-looking LFS construct. :-)

comment #9:

> If I understand correctly, it requires a log-in by the user and wraps over their shell. We can't force users to do this! A principle of Maneage is to have no effect on the host ;-).
>

Yeah as I mentioned, JAIL is a login shell.
And It is going to be used as the default shell of a user.

I suggest going through the full configuring Jail section. It is a quick easy read.

But, as I mentioned at the top of my comment, the reason I shared this site is to see what a minimal chroot environment is composed of.

If you remember, the discussion last time reached this point that we couldn't do a chroot to the project's folder because some system components didn't exist in the project folder such as /bin/bash,...
  

> You also mentioned one-time engagement of root privilege, which we also can't assume in Maneage.
>
> Please correct me if I am wrong ;-).

Now getting back to my last argument, imagine the following scenario on a server:

1- the server admin has created a user for jailed chroot. This user has /usr/local/bin/jail as its defau;t shell in /etc/passwd or what other user management system, the server is using.

2- You as an ordinary user login to your own shell.

3- you create a user namespace.

4- inside the user namespace, you login to that user created in step 1 and you run your project with that user.

Of course, I am not suggesting this in general. Only, as a test in Server environments and as a very raw idea.

A quick update on this on how to create the chroot environment, in terms of what block devices, ... would be required from /dev, ....

A nice login shell called jail from 2001, and the discussion there,

http://www.jmcresearch.com/projects/jail/

Of course, for us, the mechanics of the perl script which would create the minimalist chroot environment has the highest priority. This could nicely fit to the philosophy of creating the minimalist environment required to build and run a project.

The code can be downloaded from
http://www.jmcresearch.com/projects/jail/

I will be working on combining this with an unprivileged user namespace.

However, the general Idea of a jailed login shell in a server environment is very effective and would require one-time engagement of root privilege.

Very nice summary Mohammad-reza, I really enjoyed reading it and also learnt a lot!

As an initial test, I made a 'temporary' directory in my home account on one of our servers. Just to confirm that 'chroot' doesn't work, I tried 'chroot'ing to it and got an "Operation not permitted" result:

$ chroot temporary/
chroot: cannot change root directory to 'temporary/': Operation not permitted

Then I started following your examples. The first command worked and I became "nobody":

[me@server ~]$ unshare -U bash
[nobody@server ~]$

The second command also worked and I became "root":

[me@server ~]$ unshare -U -r bash
[root@server ~]$

The third command also worked, just to confirm that this root is fake, I also tried going to the root directory and writing something there:

[me@server ~]$ unshare -U -r -m bash
[root@server ~]$ cd /
[root@server /]$ echo "test" > test.txt
bash: test.txt: Permission denied

Then, in my home directory, I ran the first 'chroot' command above and this time it didn't complain about permissions any more (so it passed that phase!). But it complained about not finding '/bin/bash' in the newly rooted directory (which was expected because the directory was empty!):

[root@server ~]$ chroot temporary/
chroot: failed to run command ‘/bin/bash’: No such file or directory

So this does seem like a promising path! What do others think?

'unshare' is part of 'util-linux', which also builds on macOS. I really wonder how this would work on macOS. Raul, if you get the chance later, can you try it out?

But over-all, as you said, if we can do a 'chroot', then the next step would be task #15390 (Installing GNU C Library within project). Fortunately some good progress has been made on that front, with the basic Make recipes being written for a successful ly usable C library, but there is still some work necessary to for the later parts of that task...

== A QUICK UPDATE ==

I am following/evaluating user namespace sandboxing.

For some keywords and resources, you may refer to the following:

• firejail man-page: a brief and short description of Linux sandboxing and related keywords
• a structured talk by Michael Kerrisk on user namespaces
  • https://www.youtube.com/watch?v=73nB9-HYbAI
  • https://man7.org/conf/meetup/

NOTE: Michael Kerrisk is the maintainer of Linux man-pages; as you might know, the man-pages were originally created/published as the main documentation of UNIX.

I must confess that the scenario you described with "rm -rf" happened to me once! Fortunately I wasn't root, but before I could understand the mistake, my home directory was gone!!!

But Looking back at that experience, it happened while I was developing my own project (it was a simple typo that can happen in any script!).

Running something like Lintian on every test run of the project will make it slow and probably many will just disable it!

Generally when packaging Gnuastro for Debian I like the Lintian wornings! Like the spell-checking in the source code and comments ;-)! But I agree maintaining something like Lintian will be too much work for us now!

In parallel to the security-oriented/security-related discussions in

• https://savannah.nongnu.org/task/?15694
• https://savannah.nongnu.org/task/?15696
• https://savannah.nongnu.org/task/?15389
• https://savannah.nongnu.org/task/?15686

I am opening this task to discuss the implementation of an effective/simple/platform-independent sandboxed environment for the execution of Maneage project scripts.

OBJECTIVE

As a first step, we might try limiting filesystem access of Maneage project scripts to their parent directory while forbidding their access to specific locations/files (such as all the hidden files and directories inside $HOME) even if the Maneage project scripts parent directory contains such locations.

MOTIVATION

As a scientific research project management/workflow pipeline, Maneage has been designed with the purpose of providing transparency and clarity to the workflow of scientific projects branched from it. This is achieved by writing scripts and taking advantage of Make-files to create the relevant workflow. This means that one would gain full visibility to data lineage and workflow of the Maneage project by going through the project scripts and MakeFiles.
 
It is true that no Maneage project cannot NOT PROVIDE these scripts and MakeFiles, however, in practice a thorough review of scripts and the MakeFiles could not be that easy.

It is going to be easy to miss things specifically when an inexperienced Maneage project audience is trying to first test and then to understand another person's research workflow for his own sake. The story is different when someone wants to create his own Maneage project.

After two to three Maneage projects, that person would surf through the scripts and the MakeFiles very quickly and would not even have the urge to run the scripts to understand the workflow. When clarity is achieved regarding the workflow, to check the results or to play with the workflow, s/he might find it necessary to run/modify the project.

Long story short, It is not practical to fully transfer the responsibility of reviewing Maneage branched projects codes to either the audience or the Maneage developers.