-
Notifications
You must be signed in to change notification settings - Fork 736
Fix client key permissions #4194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
caused by a change in logic in when permissions are set making the permissions for this file different from before. #4193
|
How come this affected only Windows? Or was that not so? |
I never checked if it affected the other platforms, I wouldn't be surprised if it did |
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.
I tried this and it worked fine on a pristine install on Windows, but read-by-all private key?
Yep, unfortunately that's how it was and as far as I know how it needs to be without a big change in the clients. |
The failure was repeated for me: hypothetically (might) also relate to residue left over from 1.15.1 and/or 1.16 RC? |
This fix doesn't affect existing files so residue from 1.16 RC would still cause this error |
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, we've discussed and I have understood why this isn't a problem.
@Sploder12 thanks for the fix! If I understand it correctly, we're basically falling back to the parent folder's permissions, right? The user who installed the multipass would naturally have the proper permissions to the parent folder; therefore, they can access the file, but not the others. |
Yep! |
this should fix some of the issues with permissions being not restrictive enough.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4194 +/- ##
=======================================
Coverage 89.30% 89.31%
=======================================
Files 259 259
Lines 15684 15685 +1
=======================================
+ Hits 14007 14009 +2
+ Misses 1677 1676 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
| DWORD convert_permissions(int unix_perms) | ||
| { | ||
| if (unix_perms & 07) | ||
| if (unix_perms == 07) |
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.
Why does this need to receive an int, rather than the original perms? All of set_permissions should be able to use constants therein, rather than magic numbers, no? Anyway, something for another time.
|
@xmkg I am going ahead and merging this, to speed things up, but if you could still review it after the fact (either here or in a new RC), I'd appreciate it. Thanks! |
There was a change in logic in when permissions are set for ssl certificates which caused newly created client certificates to have overly restrictive permissions. This fixes that. Also there was a bug where unix permissions weren't converted to Windows permissions correctly. This fixes that. Setting the permissions of the file to read by everyone does not change security since the parent folder maintains the user only access. However, in the future it would be nice to give read permissions directly to the user instead of everyone. closes #4193


There was a change in logic in when permissions are set for ssl certificates which caused newly created client certificates to have overly restrictive permissions. This fixes that.
Also there was a bug where unix permissions weren't converted to Windows permissions correctly. This fixes that.
Setting the permissions of the file to read by everyone does not change security since the parent folder maintains the user only access. However, in the future it would be nice to give read permissions directly to the user instead of everyone.
closes #4193