-
Notifications
You must be signed in to change notification settings - Fork 653
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
Change file permissions on instances #3715
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3715 +/- ##
=======================================
Coverage 88.94% 88.95%
=======================================
Files 256 257 +1
Lines 14584 14626 +42
=======================================
+ Hits 12972 13010 +38
- Misses 1612 1616 +4 ☔ View full report in Codecov by Sentry. |
5a257a8
to
1e245a5
Compare
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.
Looks good, it seems that codecov wants to see test coverage for some lines:
- if (!MP_PLATFORM.set_root_as_owner(path)) in
write_to
extract_image
doesn't seem to have tests for it at all?
I have decided that the vm_image_vault tests are out of the scope of this PR. This is because writing tests would require a significant refactor of unrelated code (see 1653 in Jira). |
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.
Thanks for your work on this @Sploder12! Tackling these parts of the code can be tricky :)
Since this PR is closely related with #3782, there might be some overlap. But, here are some thoughts I had reviewing this:
- Existing instance directories/files do not have their permissions changed, only new instances.
- Is there a reason to apply permissions specifically to
cloud_init_iso
and instance directories and not to the other files stored within thedata_directory
andcache_directory
? - Would it be better/easier to apply blanket permissions on the
storage_directory
/cache_directory
/data_directory
indaemon_config
? That would solve 1 if it doesn't interfere with 2. - Instead of the name
set_root_as_owner()
, how abouttakeown()
? If need be, it could default to root/admin with an option to set ownership to the current user. That would follow pretty closely the Windows definition oftakeown
.
|
I guess covering the whole directory would be safer for the future and agree with principle of least privilege better. We can always expose any thing we need on a case by case basis. |
7216696
to
3af663c
Compare
3af663c
to
bafbd01
Compare
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.
Initial review pass and I noticed some things that I think could be improved. Will make a more detailed review afterwards.
By setting permissions on the top level data/cache directories, all sub-directories should inherit those permissions, correct? If so, some of the code could be cleaned up.
@@ -189,6 +190,16 @@ std::unique_ptr<const mp::DaemonConfig> mp::DaemonConfigBuilder::build() | |||
std::make_unique<DefaultVMBlueprintProvider>(url_downloader.get(), cache_directory, manifest_ttl); | |||
} | |||
|
|||
if (!storage_path.isEmpty()) | |||
{ | |||
MP_PERMISSIONS.restrict_permissions(storage_path.toStdU16String()); |
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.
There is some overlap here where the permissions on the storage path is already being set.
else | ||
{ | ||
MP_PERMISSIONS.restrict_permissions(data_directory.toStdU16String()); | ||
MP_PERMISSIONS.restrict_permissions(cache_directory.toStdU16String()); |
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 did you use toStdU16String()
and not toStdString()
? Something to do with valid characters in the Windows filesystem?
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.
yep, std::filesystem::path
's constructor from std::string
is assumed to be the "native narrow encoding", which is not guaranteed to be UTF-8 (I think). But the char16_t
constructor does handle UTF-16 conversion.
@@ -669,7 +670,9 @@ QString mp::DefaultVMImageVault::extract_image_from(const VMImage& source_image, | |||
const ProgressMonitor& monitor, | |||
const mp::Path& dest_dir) | |||
{ | |||
MP_UTILS.make_dir(dest_dir); | |||
MP_UTILS.make_dir(dest_dir, QFile::ReadOwner | QFile::WriteOwner); |
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.
If the top level data_directory
and cache_directory
are having their permissions and ownership set at daemon start, is there a necessity to individually set permissions and ownership of every instance directory?
{ | ||
void set_single_permissions(const Path& path, const QFileDevice::Permissions& permissions) | ||
{ | ||
QString qpath = QString::fromUtf8(path.u8string()); |
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.
There's some funny conversion going on here. QString
to u16String
to u8string
to QString
.
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.
yeah, QString
-> u16String
-> std::filesystem::path
-> u8string
-> QString
-> std::string
-> char*
. I could probably get it to QString
-> u16String
-> std::filesystem::path
-> std::string
-> char*
but any better than that would require some pretty massive changes to everything.
This PR changes file permissions on Multipass cache and data directories to be read/write only by root. Previously the files could be read by all.
MULTI-1403