Fix incomplete implementation of readonly for VfsPosix #17713
Conversation
|
Code size report: |
d707d58 to
b795cd2
Compare
I noticed that operations such as unlink could be performed on a nominally read-only VfsPosix. Signed-off-by: Jeff Epler <jepler@gmail.com>
b795cd2 to
b1dd470
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #17713 +/- ##
==========================================
+ Coverage 98.44% 98.46% +0.01%
==========================================
Files 171 171
Lines 22208 22218 +10
==========================================
+ Hits 21863 21876 +13
+ Misses 345 342 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Signed-off-by: Jeff Epler <jepler@gmail.com>
b1dd470 to
cc65036
Compare
| temp_dir = "micropy_readonly_test_dir" | ||
| try: | ||
| os.stat(temp_dir) | ||
| raise SystemExit("Target directory {} exists".format(temp_dir)) |
There was a problem hiding this comment.
other tests just print "SKIP" here and raise SystemExit; suggest following those
There was a problem hiding this comment.
I saw this convention in other tests but I'm not sure how I feel about it.
It feels like "a directory happens to exist in the filesystem that prevents a test from running" is an error, not a skip-this-test situation. For instance, if I'm not keeping an eye on things, a botched run of this test that leaves the temporary directory will just SKIP and not actually test anything.
If you're happy with the way other tests do it, I of course can change it.
There was a problem hiding this comment.
It feels like "a directory happens to exist in the filesystem that prevents a test from running" is an error, not a skip-this-test situation. For instance, if I'm not keeping an eye on things, a botched run of this test that leaves the temporary directory will just SKIP and not actually test anything.
Yes, you're right. It is easy to accidentally have tests SKIP when you actually want them to run, see eg c1c73d9
So, let's leave it as you have it.
When this configuration flag is set, VfsPosix instances can be written. Otherwise, they will always be created "read only". This flag is useful when fuzzing micropython: Without VfsPosix, the fuzzing input script cannot be read; but with writable VfsPosix, fuzzing scripts can potentially perform undesired operations on the host filesystem. Signed-off-by: Jeff Epler <jepler@gmail.com>
cc65036 to
c4a7ce4
Compare
Summary
I noticed that operations such as unlink could be performed on a nominally read-only VfsPosix.
Fix all these operations, and then add a compile-time configuration option MICROPY_VFS_POSIX_WRITABLE. Disabling this option ensures that a VfsPosix instance is ALWAYS read-only. This may be useful when fuzzing micropython, which can otherwise make modifications to the host filesystem.
Testing
I added a new test for VfsPosix read-only mode.
Trade-offs and Alternatives
Initially, I structured the test as an importable module so that other filesystems could potentially re-use the same test code; however, most(all?) other filesystems are based on block devices, and I don't think they have the same problems with needing to add readonly checks in each code path since they just ensure the block write function cannot be called. It also turns out ci_webassembly_run_tests failed due to inability to import the auxiliary file, so I went with the one-file implementation after all.