<issue_start><issue_comment>Title: Feature request: Multi-user setup
username_0: I would like a multi-user feature where every server is running on a different user. You don't need to give pufferd root rights, just for adding new users. You can set up sudo so it would only offer the adduser command, and only under certain conditions (like prefixed users or something).

This would solve mostly the issue that servers can change each others files e.g. in case of maliciously inserted scripts or just bugged routines deleting everything or so. On the other hand it would probably make the whole thing more secure, as servers can access the pufferd directory afaik, right?

Knowing that this would require huge changes, please consider giving your opinion to the public.
<issue_comment>username_1: Really, making them users would not really "secure" it any more. I do see the benefit it'd solve in the scope of rights to other files, but I'd also argue using docker would do that too. 

I'll leave it open, but I don't expect to tackle it for a bit, since 1.3 is already large enough of a change.
<issue_comment>username_0: Docker is perfect for isolating the apps from the rest of the system, yes, but you've to manage Docker containers with root rights which still bugs me though I agreed using it. It would be a feature which would convince me to use your panel over other ones, I think.

But what's with the actual dockerd files? Aren't they editable by servers as well?
<issue_comment>username_1: Technically? Yes, however if you use anything except docker, we do not do any security on it, nor do we claim we do. The only security we currently truly support is via docker. 

If someone is running servers they don't know, they *should* be using docker anyways. If they know the servers, then doesn't really matter that you can access part of the system.
<issue_comment>username_1: I can see this type of support being added as a "plugin" to pufferd, something which I've been trying to work up where I can. I built the internal system to be mostly able to support 3rd party extensions, which could include the actual driver for the way servers get ran on the system (standard cli, a tty wrapper, and docker are 3 we have built in), and it's designed to be expandable.

I'd probably go that route with it. Add support for defining custom environments and then push it as a "you can install this module to get that functionality" type deal, instead of embedding it. Windows support especially would be a nightmare, if not impossible, and I'm already disabling everything already with Windows.
<issue_comment>username_0: Is it already recommended taking a look at the expendable driver system? Could try some things.
<issue_comment>username_1: The structure for how stuff runs is already in place, it's just not designed to dynamically register stuff yet. I've been playing with it with the new "operation" modules (the types of things the installer, pre, and post can do), but if that works out, I'd carry it over.

You can certainly start looking at it, the code would barely differ if it was embedded vs a module.

I'd start really with how docker does it, since it's the most distinct of the 3: https://github.com/PufferPanel/pufferd/blob/master/environments/docker.go
<issue_comment>username_0: Forgot it is written in Go. Need to level up my Go skills before I can do such things ^^