Unix user mapping

[leo9800]

As discussed at #317 and #184, a feature may be implemented as below:

• [😀already implemented] authenticate user with linux PAM
• [😀already implemented] optionally, allowlist or denylist could be implemented
• [🤔not yet implemented] create/modify files, directories as the identity of authenticated user, optionally, anonymous users are mapped to nobody

In this scenario, which files/directories a user could access (read/write) depends on unix filesystem ownership (and ACLs) and mode. With this feature, it is perfect for a file-sharing service that provides consistent file ownership and permission with OS and other user/ownership-awared networked filesystem services. (e.g. NFS, SMB)

This feature was discussed at #317 while the conclusion is made that this feature is not implemented and not planned; it is also mentioned at #184 that provides a python context-based solution that won't work:

    class SetUID:
        def __init__(self, user_name):
            self.user_pwd = pwd.getpwnam(user_name)

        def __enter__(self):
            os.setegid(self.user_pwd.pw_gid)
            os.seteuid(self.user_pwd.pw_uid)

        def __exit__(self, type, value, traceback):
            os.seteuid(0)
            os.setegid(0)

as os.seteuid() and os.setegid() in the class destructor would fail as the process is running as a non-privileged user.

[leo9800]

The setuid() and setgid() system calls may not be invoked by the daemon itself, because:

• The daemon is started as root
• setuid(1000) is called to impersonate a specific user that just made a successful login, says, uid=1000
• setuid(0) is invoked when the daemon wants its original UID, but it fails.

To tackle this issue, a filesystem-helper (abbrevated as FH or FSH from now on) may be implemented to handle file system operations, including open(), read(), write(), unlink(), mkdir(), rmdir(), etc. setuid() and setgid() syscalls are invoked by FH, not the daemon itself.

When FH is invoked, it communicates with the daemon with IPC by setting up a unix-domain-socket (UDS) in /tmp, e.g. /tmp/fh-{uid}-{pid}.sock. the mode of this socket file should be set to 0700 to prevent it from being accessable by other users, while the daemon is run as root, it could access the socket properly.

The full procedure is described as below:

• the daemon (wsgidav) starts
• successful user authentication is made
• daemon check if FH for the authenticated user has been spawned, if not, spawn one.
• daemon receives requests from user-agent
• daemon manipulates file system by command corresponding FH and receive responses from FH via UDS
• daemon response user-agent

Multiple python RPC implementations had been evaluated for the protocol between the daemon and FH, initially JSON-RPC which talks on stdin/stdout instead of UDS, but performance was miserable, probably due to huge encoding amplification when handling binary payloads with JSON; then comes RPyC over UDS, it won't performant decently either; finally I gave gRPC/ProtoBuf a try and it seems to be the best amoung the 3.