Turns out, the previous approach that I talked about involving the sending of keystrokes across a standard channel to the server was filled with security vulnerability. Turns out that sending keystrokes across the socket has the same kind of repercussions as sending commands across the socket. Additionally, it would essentially be a key logger with the right kind of man in the middle attack. So I should thank Aakash for that critical insight that I missed while considering that approach.
So, I decided to just stick with the su approach, but instead of trying so hard
to get the user environment from a program not running in that space at all, I
decided to use the existing server client architecture.
However, I modified this to only get what I need the most from the server, the fact
that it is from the user space. So, if I would be able to get the env from the
server itself and just pass it on to the client, it would essentially be like emulating
to the program that it is in fact from the user space.
su would take care of doing the important part like setting up groups and stuff,
while our rust program would set the right environment variables for the child process.
The daemon in this case, would bind to a socket and listen for connections from the client. The moment the server connects to the daemon, it shuts down the socket connection and retains the environment.
This implementation is enough to get the whole setup working. However, there is a lot of scope to improve this still.
To keep the environment updated
This model can be changed a bit such that the server can actually be daemonized and be persistent across the process life cycle. This means that every time a process is spawned, the server would quickly respond with the new environment. This would also ensure that any changes to the environment get detected directly. Hence, up to date and awesome to use.
Regardless, this still shows quite some potential and if it is finalized it would kick start most of the other work in the project.