[Fix #127] Data dir permission is too wide

[ssiuhk]

to:
cc: @subspacecommunity/subspace-maintainers
related to:
resolves: #127

Background

Data directory default permission is too wide that allows anyone from the system to read the configuration files

Changes

• Summary of changes

• Changed umask of the user during the section creating configuration files
• Added special handling for config.json to update the permission upon next start-up

Testing

Using the updated entrypoint.sh

[root@localhost subspace]# rm -rf data
[root@localhost subspace]# docker-compose up -d
Creating subspace ... done
[root@localhost subspace]# ls -alh data
total 8.0K
drwxr-xr-x. 3 root root 42 Jul 26 02:29 .
drwxr-xr-x. 8 root root 156 Jul 26 02:28 ..
-rw-r--r--. 1 root root 4.3K Jul 26 02:29 config.json <- It was generated at later stage by the subspace process
drwx------. 4 root root 96 Jul 26 02:28 wireguard <- Permission tightened
[root@localhost subspace]# docker-compose restart
Restarting subspace ... done
[root@localhost subspace]# ls -alh data
total 8.0K
drwxr-xr-x. 3 root root 42 Jul 26 02:29 .
drwxr-xr-x. 8 root root 156 Jul 26 02:28 ..
-rw-------. 1 root root 4.3K Jul 26 02:29 config.json <- Permission tightened upon 2nd run
drwx------. 4 root root 96 Jul 26 02:28 wireguard

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
No Duplication information

[agonbar]

Testing this, it seems to work, the config is no longer public, the folders and files all get the correct permissions and the server keeps access to them on startup.

Only thing missing, the new files in clients and peers get 644 permission from subspace, but at least this is an improvement.

[ssiuhk]

Yeah, for that probably need to change default umask when starting the subspace application, but not sure about impact of that.
Anyway, upper level folder locked up should be good enough

[jacksgt]

Yeah, for that probably need to change default umask when starting the subspace application, but not sure about impact of that.
Anyway, upper level folder locked up should be good enough

Thank you for this patch! I really appreciate someone talking a look at the small security details.

I don't think changing the umask will have any negative impact, since it only affects newly created files (i.e. there should be no regressions for people upgrading).