Careful there. You are only a half dozen abstraction layers away from reinventing NixOS.
As for your question, the best way is to put it in a file that is then read by the chroot script and delete later.
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Careful there. You are only a half dozen abstraction layers away from reinventing NixOS.
As for your question, the best way is to put it in a file that is then read by the chroot script and delete later.
Preferably, put the variables into a temp file (e.g. using mktemp
) and bind-mount that file somewhere into the chroot directory, so you can source it from within that environment.
That way the critical information, like the passwords, at least only gets to live in volatile memory and won't stick around on the host system after the reboot. That limits the exposure somewhat.
Careful there. You are only a half dozen abstraction layers away from reinventing NixOS.
Pack it into a json or CSV oneline string and shove it in a CLI password manager you can access in a scriptable way from both users. (I use the linux tool, 'pass' for this).
Alternatively, save it to a dropfile that only both users can access.
Why use variables and put it in json or simple text file which u can read later
i dont know if it will be safe because of ROOT_PASSWORD USER_PASSWORD and ENCRYPTION_PASSWORD
Passing them as arguments can be even worse - depending on the configuration, process arguments of running processes can be seen by everything running on the machine.
But I suppose u are working in live environment loaded from iso ,so u should be already comporissed then if some process can read ur files. What's ur threat model
It would be more secure if the credentials are in an in memory SQLite Database but that would require you to use something other than the shell. You would need to do a hardware key or have the user do a bootstrap password or have an API that uses a public key to authenticate the remote process passing the credentials