-
Notifications
You must be signed in to change notification settings - Fork 3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
safer os.chmod for wallet files and config: set perms before write
Set unix file permissions first, before writing data.
- Loading branch information
1 parent
6d37e46
commit f495511
Showing
3 changed files
with
7 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
f495511
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit will make issues like #8409 fail harder. This will not write anything to config/wallet if chmod fails for any reason.
f495511
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, but I think that is desired.
It was a bug before that we wrote data first and set permissions after.
If we want to loosen this, and accept chmod failing, that might be ok, but that is a design change that can be done separately.
Even if we silence exceptions raised by chmod, chmod should run first: so that on systems where it works, we don't leak sensitive data.
Re the config file, it should have reasonable unix permission as its contents are not authenticated in any way. If we cannot set
0600
, we should hard fail. Note that even being able to read the config file is security sensitive, as it contains the rpcpassword.For wallet files re storage.write(), I guess we could tolerate chmod failing (as in #8997).
f495511
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, however I think dumping an exception on the user is not the solution.
This should become a warning/error message dialog.
What we can do is
stat
the file after (failed)chmod
, or evenstat
the path towards to the file. If the permissions on the file or the path towards it are acceptable, we could accept a failingchmod
operation (as that would imply the user has taken sufficent precautions)f495511
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@accumulator contrary to what I said this morning, I now thing this commit is fine.
The exception is rare (two cases reported), any every time users seem to be doing weird unexpected things.
f495511
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can look into this more if we start getting more reports. note that this code has not changed in a long time, so if chmod was regularly failing we would have more reports or users complaining.
The two reports we have are for wallet files outside the datadir, with potentially weird filesystem settings. In case of these niche failures, I think it is an okay to just log something the user might see (so as a warning+) and leave it at that. It would be overkill to implement some GUI dialogs and the like - these cases are so rare that that code would never get tested and probably just break over time.
Anyway, the diff suggested in #8997 (comment) would cover the two existing reports we know of. In particular, I suggest we only ignore the PermissionErrors, and propagate other errors. I think we could just do that and revisit if we have more examples.