Merge ~chad.smith/cloud-init:tests-fix-root-os-access-leak into cloud-init:master
| Status: | Merged |
|---|---|
| Approved by: | Scott Moser on 2017-09-15 |
| Approved revision: | e19de87fdae9fb58d39ac415b73fa37e6b6e1e83 |
| Merged at revision: | 024ecc1f758d36cc0aa5ebce65704eed6bd66d45 |
| Proposed branch: | ~chad.smith/cloud-init:tests-fix-root-os-access-leak |
| Merge into: | cloud-init:master |
| Diff against target: |
170 lines (+26/-58) 2 files modified
cloudinit/config/cc_resizefs.py (+4/-8) tests/unittests/test_handler/test_handler_resizefs.py (+22/-50) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Server Team CI bot | continuous-integration | Approve on 2017-09-15 | |
| Scott Moser | 2017-09-14 | Approve on 2017-09-15 | |
|
Review via email:
|
|||
Commit Message
resizefs: Drop check for read-only device file, do not warn on overlayroot.
As root user, os.access(<path>, os.W_OK) will always return True so that
path will never get executed. Also avoid a warning if the root is
overlayroot, which is the common case on a MAAS booted 'ephemeral' system.
Description of the Change
resizefs: Drop check and tests for read-only device file
As root user, os.access(<path>, os.W_OK) will always return True so that path will never get executed as Scott pointed out. Also, on a real read-only iscsi devpath, resizefs doesn't perform an operation on a filesystem it recognizes as read-only. It may emit a warning, but not cause a traceback.
| Scott Moser (smoser) wrote : | # |
PASSED: Continuous integration, rev:675996d25dc
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Chad Smith (chad.smith) wrote : | # |
I'm not quite sure what we should do here. You are right that root user will likely never see os.access(W_OK) as False because root's a privileged user so the perms don't matter.
Also, it seems that in containers we fail to resize up at cc_resizefs line 197 on ENOENT so generally trying to account for is_container checks below in the os.access and stat.S_ISBLK
conditionals feel like wasted logic. We could just check mode values instead of os.access like this:
os.stat(
I know there must be a better way here.
But ultimately, do you know if there are device files that would be read only for root?
- 1367b2b... by Chad Smith on 2017-09-14
PASSED: Continuous integration, rev:1367b2b911d
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
- e19de87... by Chad Smith on 2017-09-15
| Scott Moser (smoser) wrote : | # |
Approve.
I've re-worded commit message some and am pushing after a tox
PASSED: Continuous integration, rev:e19de87fdae
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/


So did this just expose an *actual* bug ?
"root user still sees read-only files as writable so the unittests would fail"
If root user sees read-only files as writable, and cloud-init runs as root,
would we ever take that path ?