Allow different users in the same group to share a session.

[markrwilliams]

I understand from the CONTRIBUTING.md document that the project doesn't have the capacity to field random feature PRs while it works on its roadmap. And this random feature PR is a sketch that doesn't even have tests!

...but, @fzakaria encouraged me to open it to gauge interest. No worries if the answer is everyone's too busy to review or merge, but I'm totally willing to iterate on it -- I have a sequence of ideas about how this could be evolved into a more secure method of collaboration -- and, you know, add tests too.

Anyway, here's what's in the commit:

Adds a ZELLIJ_SOCKET_GROUP environment variable that specifies the group by name that should own the Zellij sockets and socket directory.

When this environment variable is set for a Zellij server, it will chown the Zellij socket directory and session socket to be owned by the named group with group read and execute (list) permissions set.

When this environment variable is set for a Zellij client, it will check that Zellij socket directory is owned by the expected group.

Example usage:

As user foo:

[foo@localhost:~$] id --name --groups
zellij-collab
[foo@localhost:~$] ZELLIJ_SOCKET_DIR=/tmp/example-sockets ZELLIJ_SOCKET_GROUP=zellij-collab zellij
[foo@localhost:~$] ls -lad /tmp/zellij-sockets/
drwxr-xr-x 2 foo zellij-collab 4096 Jun  7 00:00 /tmp/zellij-sockets/

As user bar:

[bar@localhost:~$] id --name --groups
zellij-collab
[bar@localhost:~$] ZELLIJ_SOCKET_DIR=/tmp/example-sockets ZELLIJ_SOCKET_GROUP=zellij-collab zellij attach

[imsnif]

Hey - thanks for giving this some thought.

This feature actually is in the roadmap in a more subtle way as part of #1401. But I'm afraid the implementation will have to be a bit more involved:

Having two users on the same machine share a session will have to involve an internal permission/security mechanism that I call "multiple backends", which is similar to the one that will need to be implemented for the web client/server. Each user on the machine will have their own "backend", meaning terminal/plugin panes that belong to them and that only they can control access to.

If I as "user1" want to open a terminal, I must have the ability to control access to this terminal so that "user2" also connected to this session can't use this terminal as if it were me without me explicitly letting them do this. This would be like giving "user2" access to my keyboard. They would be able to run commands as me, to access my files and to do whatever they like as if they were me.

Zellij must manage this on its own, allowing "user1" to not give "user2" access to their terminals at all (then they will appear blank to "user2"), to only give them read access to the terminals (they will be able to read the viewport but nothing else) or give them full read/write access.

This should be configurable at runtime for every terminal pane and include a built-in plugin to follow these permissions and modify/revoke them.

I realize this is much more involved than this PR, but unfortunately we have to do this in order to provide this feature. Not doing so would be a glaring security vulnerability: essentially anyone who would connect to the same machine and the same Zellij session would be able to "be" the other user without anyone even knowing this happened by using their terminals.

Once this is in place, we'll use this in order to implement #1401 in a similar way, except the users will be across different machines: each user having their own "backend" and terminals that they can control permissions to (imagine for example a different tab per machine/user to help visualize this: I can view a tab from a different user/machine, but can only enter commands into those terminals if the user owning this machine allows me to).