Epic: rewrite our auth methods in rust
Currently, we have 2 custom auth methods in our tarantool fork:
-
md5(for postgres-compatible authentication in pgproto). -
ldap(for fstec certification compliance).
Both are implemented in C and integrated into tarantool's auth framework.
-
md5has a rather slim set of dependencies (vendored hash function impls and such), but it's fair to say that its C implementation has a good deal of boilerplate and looks bulkier than it otherwise might be. Furthermore, recently we've had a "pleasure" of debugging a nicely hidden accidental out-of-bounds write in one of its functions. What's worse, even an ASan-enabled build (clang 18) failed to detect this bug
- Arguably,
ldap's current C impl is even more problematic. First, it depends on two native shared libraries, libldap & libsasl2, which have to either be built (proven to be problematic, has caused a lot of maintenance headache in the fork so far) or installed into user's & dev's distro of choice (no uniform way to describe that). Second, at the moment of writing (2024-09-06) it spawns a new coio task (in a threadpool) every time it has to authenticate a user, which is less than ideal. In a rust rewrite we could use ldapico, but any other impl will probably suffice.
All things considered, it'd be nice to design an API for rust-based auth methods in Picodata/Tarantool, then rewrite those auth methods in rust. That will help us:
- make it easier to maintain and patch auth method impls (no need to coordinate multiple patches),
- eliminate those cumbersome native dependencies from both tarantool fork and Picodata,
- make it easier to develop new auth methods (courtesy of rust-the-language),
- prevent certain stupid bugs from happening.
Initially, we could prototype the API in Picodata, but in the end it should probably land in tarantool-module. The method impls should stay in Picodata.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
- #123925.2 - LTS
