Repository: archlinux/archinstall

Issue:
Add support for running arch-chroot commands as non-root
As suggested in feedback from @phisch, allowing programmers and users to run chroot:ed commands as non-root would be very helpful. Assuming the installation has a non-root user to chroot into, modifying the following lines:
https://github.com/Torxed/archinstall/blob/skip-partitioning/archinstall/lib/installer.py#L187-L191

Allowing a `user=...` parameter would be an easy addition.
I'm parking this until v2.1.3 unless someone else wants to give it a go because the backlog for v2.1.2 is getting quite complex as it is :)


Discussion:
As far as I know, arch-chroot has no concept of other users. Also, if I recall correctly, due to the way we bind mount stuff, you can't really run stuff as a regular user on the chroot. So, that would be a no-go from the start, unless there's some patching on arch-chroot or we mess with mounting our own chroot.
@grazzolini `arch_chroot(f"su {user} -c 'echo ~'")`

Since there is a wrapper to add users, that wrapper can store a table in memory, and `arch_chroot` could look up if the user is inside this table, or just trust that the person writing the script knows that the user exists.

Very naive example:
```python
def arch_chroot_user(user, command):
  arch_chroot(f"su {user} -c '{command}'")
```

This is probably a bigger change, but any opinions on an interface that looks like this instead? :)
```python
def arch_chroot_user(user, command):
  arch_chroot(['su', user, '-c', command])
```
This would be more resistant to command injection issues.
The thing is, last time I tried to use su/sudo inside the chroot (for example, to build something from the AUR), it didn't work due to the way things are mounted. I suggest that you try first to run stuff inside arch-chroot as a different user, before writing any code for this.
@grazzolini https://github.com/phisch/dotfiles/blob/master/.install#L117
This line and the 3 below allow users of the group wheel to use sudo without password, clone and install paru (aur helper) as a user other than root, use paru to install a bunch of applications and then disable the temporary wheel without root hack again.
> @grazzolini https://github.com/phisch/dotfiles/blob/master/.install#L117
> This line and the 3 below allow users of the group wheel to use sudo without password, clone and install paru (aur helper) as a user other than root, use paru to install a bunch of applications and then disable the temporary wheel without root hack again.

Sure, but is it working? Do the packages work?
Yes of course, i tested this multiple times.

> arch_chroot(['su', user, '-c', command])

Didn't see your comment first @kpcyrd. My example was just a naive one, i have no idea how to write good python code :P
As mentioned in another issue, would potentially this add something to the table: https://github.com/Torxed/archinstall/blob/59994c1ffdcc916f782d50e248316790fec70974/archinstall.py#L1117

It would allow for actual actual system usage from outside the system and probably circumvent some potential issues running as the user?
> This is probably a bigger change, but any opinions on an interface that looks like this instead? :)
> 
> ```python
> def arch_chroot_user(user, command):
>   arch_chroot(['su', user, '-c', command])
> ```
> 
> This would be more resistant to command injection issues.

I think there's still command injection issues here too, unless we stop using `shell=True` I would say.
This is something we've discussed a bit over the years actually if this would be a problem. As long as the deployed scripts and examples are used, the trust is in that of the main developers and the process itself. And that's been easy to maintain as a standing ground when the script was used by 10 friends and myself.

However, as this has grown, and people might start using their own scripts.
*(especially since we support remote-profile URL's such as `https://remote.arpa/deployment.py` in the "additional profiles?" step, this might become a more relevant topic)*.

I will probably create a separate issue for security related topics, and each deserves their own.
I would like GitHub to support "security related issues" meaning they're hidden from the general public until solved or reasonable disclosure times have been met. But I don't think they do (yet).
I'm *very* uncomfortable with people getting random code from the internet and running it. So, archinstall can support this, sure. But, I think archinstall should deliver a minimal Arch installation without having to download any code from the internet.
> I'm _very_ uncomfortable with people getting random code from the internet and running it. So, archinstall can support this, sure. But, I think archinstall should deliver a minimal Arch installation without having to download any code from the internet.

I fully agree hehe :) it's also why I'm contemplating to remove the unofficial ISO, I'd like to avoid training people unconsciously to download random things off the internet, even tho I know it's safe - people shouldn't completely trust that blindly without an easy way to verify :)
Users could also use su to become their user within the chroot environment, I'm not sure how much value having them select a chroot user would be.
Honestly, after thinking this over, my vote is -1 for this one because having it give a selection of users to use chroot makes no sense and limits users in what they can do a lot more than just dropping them into a root shell. Being in a root shell would allow them to do any sort of post-install config they need and they always run can su to become their user (or multiple users if setting up something complicated). Anything else is post-install and I don't know if this is something needed in the installer.
For instance, anything regarding `postgresql` in profile installations require you to run as the user `postgres`.
This this makes a lot of sense in profiles, it's not urgent tho - so I'm parking this for the next release.

And using `machinectl console user@machine` would make sense for this.

Resolving patch:
diff --git a/archinstall/lib/installer.py b/archinstall/lib/installer.py
--- a/archinstall/lib/installer.py
+++ b/archinstall/lib/installer.py
@@ -2,6 +2,7 @@
 import logging
 import os
 import shutil
+import shlex
 import pathlib
 import subprocess
 import glob
@@ -285,9 +286,9 @@ def enable_service(self, *services):
 	def run_command(self, cmd, *args, **kwargs):
 		return SysCommand(f'/usr/bin/arch-chroot {self.target} {cmd}')
 
-	def arch_chroot(self, cmd, *args, **kwargs):
-		if 'runas' in kwargs:
-			cmd = f"su - {kwargs['runas']} -c \"{cmd}\""
+	def arch_chroot(self, cmd, run_as=None):
+		if run_as:
+			cmd = f"su - {run_as} -c {shlex.quote(cmd)}"
 
 		return self.run_command(cmd)
 


Test patch: