Ensure file permissions on gnu/linux

[E8LL4IQuU]

Checklist

• [ ] I read and understood the Contributing Guidelines.
• [+] This is not a duplicate of an existing merge request.
• [+] I believe this falls into the scope of the project and should be part of the built-in functionality.
• [ ] My code follows the code style of this project.
• [ ] I have added tests to cover my changes, wherever they are necessary.
• [ ] All new and existing tests pass.

Changes

Config files in gnu/linux are now being created with reasonable permissions, so that only the user owning the asf directory can read file contents and no one else

Changed functionality

SerializableFile Helper now applies reasonable permissions on config files after migration in gnu/linux

[JustArchi]

Chmod 600 for our own created files is a good idea, however, I'm not sure if this is something that ASF should be deciding upon itself. Example: what if user wants to create files with 640 permission by default rather than 600? Make it configurable?

Rather than this, there is already systemd setting unit called UMask which specifies what permission should default files creates by the process have, and ASF already comes with the default value of 0077 there, which means 600 permission is used by default.

Is there any use case why you want ASF to handle this rather than systemd? The recommended way of using ASF in environments where permissions make sense is to use a systemd unit, which is far more superior that ASF in this regard.

[E8LL4IQuU]

ArchiSteamFarm is indeed shipped with systemd unit that sets Umask to 0077. I'm currently running it and for some reason files are created with horrendous -rw-r--r-- permissions. There's no use to set umask in your session too, as asf is being run from asf user, which is nologin. What's more annoying is that I change permissions to let's say -rw-------, restart my system and here we are again with -rw-r--r-- on .json and .db files

[E8LL4IQuU]

And yeah sure we can go with 660, as we're enforcing those, it's probably better to have user AND group perms in case user wants to read it from group

[JustArchi]

Are you sure there isn't anything that actually changes those permission after restart? Do they stick in 600 if ASF process is not run at all, and only after you start it they change to 644?

Because what you're describing should not happen - that'd mean something is horribly wrong in ASF that it'd CHANGE default permission and to 644, there's no code that is doing that.

Moreover, I checked my own installation and all the permissions are aligned with UMask set, and nothing resets them, so this suggests something else on your system is doing that and ASF using forced 600 in the file would not fix your issue.

Majority of json config files weren't changed since half a year or so, while .db files were changed just recently, so I'd notice the difference. My .gitkeep.bak is funny example, because it comes from the times when ASF didn't have UMask yet in the systemd, hence 644 there.

[JustArchi]

I believe ASF should not change the file permission itself, it's arbitrary decision what to set it, other users might have different requirements, making it configurable makes no sense considering superior solutions exist.

The recommendation is to use UMask on systemd as the superior solution, which I verified myself that works correctly and ASF does not reset the permissions, even when writing files. For people that can't or don't want to use systemd (since they have full right to do so), I recommend to chmod config directory to 700 instead, which serves similar purpose and will not allow other users to read files further inside, regardless of their 644 permission, which is what I did myself before ASF systemd unit was a thing.

I don't believe ASF forcing permission on its new files serves any use case at all considering above. It doesn't mean 600 permission is useless, I'm using it myself, but the proper way to configure this is in systemd, shell or another supervisor, and not ASF itself - ASF purpose should be to not change the default permission unless determined necessary for operation, which is already happening.

[E8LL4IQuU]

Confirm correct ASF behaviour. problem was on my side, I was configuring 2fa on accounts by starting asf from console, so my umask of 022 was applied every time asf migrated files.