Skip to content

Conversation

@Sploder12
Copy link
Contributor

@Sploder12 Sploder12 commented Jun 30, 2025

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

caused by a change in logic in when permissions are set making the permissions for this file different from before. #4193
@ricab
Copy link
Collaborator

ricab commented Jun 30, 2025

How come this affected only Windows? Or was that not so?

@Sploder12
Copy link
Contributor Author

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

Copy link
Collaborator

@ricab ricab left a 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?

@Sploder12
Copy link
Contributor Author

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.

@holta
Copy link

holta commented Jun 30, 2025

I tried this and it worked fine on a pristine install on Windows, but read-by-all private key?

The failure was repeated for me: hypothetically (might) also relate to residue left over from 1.15.1 and/or 1.16 RC?

@Sploder12
Copy link
Contributor Author

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

ricab
ricab previously approved these changes Jul 1, 2025
Copy link
Collaborator

@ricab ricab left a 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.

@ricab ricab requested a review from xmkg July 1, 2025 10:50
@xmkg
Copy link
Member

xmkg commented Jul 1, 2025

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.

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

@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.

@Sploder12
Copy link
Contributor Author

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
Copy link

codecov bot commented Jul 1, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.31%. Comparing base (46b4059) to head (d307dbd).
⚠️ Report is 413 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Collaborator

@ricab ricab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I've verified this on Linux and Windows and all looks good now. Permissions on the root certificate, private keys, and client certificates all look correct now.

image

image

DWORD convert_permissions(int unix_perms)
{
if (unix_perms & 07)
if (unix_perms == 07)
Copy link
Collaborator

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.

@ricab
Copy link
Collaborator

ricab commented Jul 1, 2025

@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!

@ricab ricab added this pull request to the merge queue Jul 1, 2025
Merged via the queue into main with commit b7a35a3 Jul 1, 2025
23 checks passed
@ricab ricab deleted the fix-client-cert-perms branch July 1, 2025 19:42
ricab added a commit that referenced this pull request Jul 1, 2025
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

'C:/Users/USERNAME/AppData/Local/multipass-client-certificate/multipass_cert_key.pem': Permission denied(13)

4 participants