Check permissions on configuration file, not symlink #687

Merged

floatingghost merged 1 commit from erincandescent/akkoma:config-stat-symlink into develop

2024-02-16 12:19:09 +00:00

erincandescent commented

2024-02-14 17:46:01 +00:00

Contributor

akkoma.exs -> ..{something}/akkoma.exs

(No I don't know why Kuberntes does this. I'm sure it has its reasons, maybe related to ConfigMap updates)

Now, the funny thing about symlinks is that on most Unixes (except macOS and FreeBSD with a specific mount option), symlinks don't have permissions of their own. In fact, they're hardcoded to return most bits enabled when responding to a lstat(2) call; all access controls are done on the target file instead.

So use of lstat(2) here results in a false positive; we should use stat(2) instead, which follows the symlink.

(My current work around is to copy the config file into a tmpfs, which is deeply ugly)

Some discussion here

When deploying something on Kubernetes, the idiomatic way to inject a configuration file into the container is to mount a ConfigMap. However, when mounted, a ConfigMap contains symlinks which point at the actual files; something along the lines of ``` akkoma.exs -> ..{something}/akkoma.exs ``` (No I don't know why Kuberntes does this. I'm sure it has its reasons, maybe related to ConfigMap updates) Now, the funny thing about symlinks is that on most Unixes (except macOS and FreeBSD with a specific mount option), symlinks don't have permissions of their own. In fact, *they're hardcoded to return most bits enabled* when responding to a `lstat(2)` call; all access controls are done on the target file instead. So use of `lstat(2)` here results in a false positive; we should use `stat(2)` instead, which follows the symlink. (My current work around is to copy the config file into a tmpfs, which is deeply ugly) [Some discussion here](https://akko.erincandescent.net/notice/AesGkEexpVU8GGDaO8)

erincandescent added 1 commit 2024-02-14 17:46:01 +00:00