Fix ipfs/go-ipfs#4224

[jbarthelmes]

Lift (arbitrary?) restriction on file location.

Original author: @whyrusleeping

[jbarthelmes]

ipfs/kubo#4224 (comment) @Stebalien

The only remaining attack vector is confirmation: verifying that some file exists at some path. Unfortunately, that's easily exploitable with guess and check: guess the first byte, guess the second byte, etc.

I don't understand this yet.

[Stebalien]

If an attacker could access the go-ipfs API, it could use the filestore to read an arbitrary file from the disk.

[jbarthelmes]

@Stebalien

If an attacker could access the go-ipfs API, it could use the filestore to read an arbitrary file from the disk.

I still don't see the problem that the deleted 3 lines of code solve.

access the go-ipfs API

Which API do you mean? I'm thinking of these scenarios:

1. Local privilege escalation: attacker gains same read access as ipfs daemon user. Solution: restrict that user's rights. Access to $HOME is already enforced by the OS.
2. Remote attacker uses HTTP API to read from file system. Solution: Fix your network security.

Either way, restricting access to $HOME by default does not protect sensitive files like .ssh/id_* or .ipfs/config.

[Stebalien]

Let's discuss this on the main issue. The question isn't how to lift this limitation, it's should we lift it and when.

[jbarthelmes]

this should be changed too, so that dobj.FilePath saves an absolute path