recovery: add O_NOFOLLOW|O_EXCL to prevent symlink-following in recovery file creation

[kuranikaran]

WriteRecoveryInstructions() at recovery.go:94 opens the recovery README
with os.O_WRONLY|os.O_CREATE without O_NOFOLLOW. When fscrypt encrypt
runs as root via sudo, a local attacker who controls the parent directory
can place a symlink at the recovery file path, causing root to write
through the symlink and fchown the target to the attacker.

The rest of the codebase uses O_NOFOLLOW consistently:

• filesystem.go:608: os.O_WRONLY|os.O_TRUNC|unix.O_NOFOLLOW
• filesystem.go:747: os.O_RDONLY|unix.O_NOFOLLOW|unix.O_NONBLOCK

This change adds os.O_EXCL|unix.O_NOFOLLOW to align with the existing
security pattern.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[ebiggers]

Merged, thanks.

[kuranikaran]

Hey @ebiggers, thanks for the quick merge! Since this was a security fix (symlink-following allowing root to write through a symlink + fchown when fscrypt encrypt runs under sudo), would you be open to creating a GitHub Security Advisory for this? GitHub can assign a CVE directly through the advisory process. Happy to help draft the advisory details if needed.

[ebiggers]

I'm not entirely convinced this is CVE-worthy. The same issue could be claimed in any program that ever writes any file without O_NOFOLLOW, as the program could be run as root with the target directory owned by another user.

Also O_NOFOLLOW doesn't solve the problem if the parent directory is owned by that other user, as well.

Running programs as root against files owned by another user (when they are logged in and have the opportunity to concurrently change those files) just isn't a great practice.