Don't write to htoprc file if it's not owned by EUID

Because htop writes the new settings in an "atomic" fashion (that is,
create a temp file, write content and then rename the temp file to
the final name, replacing the old one), the new htoprc file could be
owned by a user that's different from the original. This can cause the
original user to not be able to access the htoprc file again.

This scenario can happen when htop is run with elevated privileges.
In Linux, this occurs when htop is run with SUID (`chmod u+s htop`).
In macOS/Darwin, this occurs when htop is run with sudo (`sudo htop`)
with the default sudoers configuration (specifically, with this
`env_keep += "HOME"` line, which is discouraged by sudo upstream).

Don't assume the htoprc file opened will be owned by the same effective
user ID. If the file's owner is different, don't write to it on htop's
exit.

Signed-off-by: Kang-Che Sung <[email protected]>

Author: Explorer09

Settings.c

@@ -331,10 +331,12 @@ static bool Settings_read(Settings* this, const char* fileName, const Machine* h
             return false;
          }
       } else {
-         // Check if this is a regular file
+         // Write the config only if the file is:
+         // (1) a regular file (not a device file like /dev/null), and
+         // (2) owned by the effective user ID
          struct stat sb;
          int err = fstat(fd, &sb);
-         this->writeConfig = !err && S_ISREG(sb.st_mode);
+         this->writeConfig = !err && S_ISREG(sb.st_mode) && sb.st_uid == geteuid();
       }
    }