Don't follow symlinks when writing htop_history

[Explorer09]

Prevent a symlink attack that allows an attacker to empty any file a user has write permission to.

[fasterit]

What is a realistic attack scenario here?

[Explorer09]

What is a realistic attack scenario here?

The attack is possible when the directory that the htoprc file resides is writable by the public or a local group. Then, suppose Mallory has write access to the directory, and he ln -s /home/alice/some_important_data htop_history to create a symlink. He can then wait for Alice to load that htoprc file and get hit.

If Alice runs htop with sudo privilege, things can get worse. I think you can get the idea.

[fasterit]

The same is true for htoprc.

$ htop
Configuration /home/daniel/.config/htop/htoprc was resolved to /etc/passwd
Cannot save configuration to /etc/passwd: Permission denied

[Explorer09]

The same is true for htoprc.

$ htop
Configuration /home/daniel/.config/htop/htoprc was resolved to /etc/passwd
Cannot save configuration to /etc/passwd: Permission denied

Gee. You motivated me to write this: #1947

[Explorer09]

For your info, the Settings_resolveSymlink function I introduced in #1947 can be easily adapted to work with htop_history file, too. If you people want it.
(The function adds a simple safeguard for symbolic links by checking the ownership of the link. It follows the symlink only if the link is owned by either root or the EUID running the htop instance.)