feat: startup permission check

[koivunej]

When running with data directory which is not writeable (but still might contain writable database files), this gives:

INFO 🏁 Starting node. version="v0.2.3-alpha-38-gf719abe"
Error: Failed to create a file in /.../tmpdir. Make sure the directory is writable by the user running pathfinder.

Caused by:
    Permission denied (os error 13)

This check might of course cause issues for some users but helping these out are always confusing, especially if the error comes from sqlite because a journal file couldn't be removed or created or whatever.

[Mirko-von-Leipzig]

I like it. I wonder if we can similarly check the database file(s) permissions somehow (if they exist of course)?

[koivunej]

I like it. I wonder if we can similarly check the database file(s) permissions somehow (if they exist of course)?

Looked at more options yesterday.

Trouble with looking at the os specific permissions, it's more difficult to resolve if we are the owner, are in group or others or have acl

Trouble looking at the sqlite open options, the read_write allows write being missing according to docs.

I think for practical ways this leaves the option of doing any write. I've previously suggested we should track sessions and up until which block have they gotten in a sort of audit table which could also be used for repairs (if we'd know that version X processed until block Y ...). I wouldn't want to continue an audit table on this.

One thing I was left thinking that this check might of course hurt someone... Any objection to me adding skip with std::env::var_os("PATHFINDER_SKIP_PERMISSION_CHECK").is_some()? @Mirko-von-Leipzig @kkovaacs

[kkovaacs]

One thing I was left thinking that this check might of course hurt someone...

Hmm, how? I think testing that new files can be created in the data directory is actually good: sqlite creates new files in that directory, so not having the permission to do so would be just bad.

[Mirko-von-Leipzig]

One thing I was left thinking that this check might of course hurt someone...

I think lets wait until that actually happens? I.. can't think of any good scenario where we can only read from the existing read-only database. I guess maybe in the future they somehow want to server a read-only snapshot with sync and everything else disabled? But they can then ask for that (weird) feature.

[koivunej]

Oki, I just have a bad track record with adding features which seemingly do no harm but were hurting docker users :)

[Mirko-von-Leipzig]

Oki, I just have a bad track record with adding features which seemingly do no harm but were hurting docker users :)

Lets run it in docker before then just to make sure :)