uid/gidmapping

[ezrizhu]

• [x] try
• [x] tests
• [ ] better sync mechanism #140
• [ ] c gidmapper #143
• [ ] docs (mention that docker needs spawned privileged and is root in the ct) (also mention below)
• [ ] test apt #6
• [ ] test/toplevel-perms.sh permissions test change (blocked by #138) [1]

[1] due to regular files not being tracked in try (tangent #150), we're also not setting the permissions correctly. e.g., if /test is owned by another user, this will not be reflected in try. This is likely outside the scope of this PR. However we can probably track this in another issue, #90 could also fix it.

Four tiers of uid/gid mapping

1. no gid mapping: Files are only accessible if the ownership is set to both current user's uid and gid.
2. unprivileged gid mapping: groups will look exactly the same inside and outside the container, the try will have access to things owned by things that one of user's group has access to aswell
3. privileged gid mapping: both a file's user and group ownership will also look and act exactly the same inside and outside try. (needs sudo, and try will have access to everything)
4. privileged uid mapping with -u set: id result will look the same.

# no mapping
ezri@pashsn3:~/try$ ./try ls -l try
-rwxrwxr-x 1 root root 21884 Feb 17 10:39 try

# unprivileged mapping
ezri@pashsn3:~/try$ ./try ls -l try
-rwxrwxr-x 1 root ezri 21884 Feb 17 10:39 try

# privileged mapping
ezri@pashsn3:~/try$ sudo ./try ls -l try
-rwxrwxr-x 1 ezri ezri 21884 Feb 17 10:39 try

# shell
ezri@pashsn3:~/try$ ls -l try
-rwxrwxr-x 1 ezri ezri 20263 Feb 17 10:42 try

# no mapping
ezri@pashsn3:~/try$ ./try id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)

# unprivileged mapping
ezri@pashsn3:~/try$ ./try id
uid=0(root) gid=1001(ezri) groups=1001(ezri),27(sudo)

# privileged mapping without user set
ezri@pashsn3:~/try$ sudo ./try id
uid=0(root) gid=0(root) groups=0(root)

# privileged mapping with user set
ezri@pashsn3:~/try$ sudo ./try -u ezri id
uid=1001(ezri) gid=1001(ezri) groups=1001(ezri),27(sudo)

# shell
ezri@pashsn3:~/try$ id
uid=1001(ezri) gid=1001(ezri) groups=1001(ezri),27(sudo)

closes #140 closes #143 closes #6

[mgree]

One other test to run: can a valid sudoer use sudo inside the container? (Feels good for running scripts that need to install things, but mostly are unprivileged.)