-
Notifications
You must be signed in to change notification settings - Fork 174
store: Centralize composefs directory creation with mode 0700 #2006
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
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.
Code Review
This pull request effectively addresses a potential security vulnerability by centralizing the creation of the composefs directory and ensuring it is created with restrictive 0700 permissions. The introduction of the ensure_composefs_dir helper function is a good refactoring that improves code clarity and maintainability by removing duplicated logic. The addition of a unit test to verify the directory permissions and the function's idempotency is also a great inclusion. Overall, this is a solid improvement to the codebase.
23e050f to
f732be6
Compare
The install-time composefs directory creation in repo.rs used create_dir_all() which relies on the process umask for permissions, potentially creating /sysroot/composefs with overly permissive modes and leaking information. Centralize the directory creation into a new ensure_composefs_dir() helper in store/mod.rs that explicitly sets mode 0700. Both the install-time path (repo.rs) and the runtime lazy-init path (Storage::get_ensure_composefs) now use this single helper. The helper also always updates permissions on existing directories, so systems installed with an older version of bootc will have their composefs directory permissions corrected on upgrade. Also removes #[allow(dead_code)] from COMPOSEFS_MODE since it is now actively used, and adds unit tests verifying the directory permissions, idempotency, and correction of pre-existing wrong permissions. Assisted-by: OpenCode (claude-opus-4-6) Signed-off-by: John Eckersberg <jeckersb@redhat.com>
f732be6 to
8b33259
Compare
| .context("Creating composefs directory")?; | ||
| // Always update permissions, in case the directory pre-existed | ||
| // with incorrect mode (e.g. from an older version of bootc). | ||
| physical_root |
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.
Minor nit but I'd prefer if we only called chmod() if we had work to do. It may not matter...but I think it might still dirty the inode even in the no-op case, causing write traffic.
Also important: At some point in the future we will need to properly handle "physically" readonly rootfs (think ISO), so we don't want to introduce new places where we unconditionally try writes.
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.
These things can be followups
| } | ||
|
|
||
| #[test] | ||
| fn test_ensure_composefs_dir_fixes_existing() -> Result<()> { |
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.
The unit test is fine and cheap, but I think this one also wants to be integration tested.
The install-time composefs directory creation in repo.rs used
create_dir_all() which relies on the process umask for permissions,
potentially creating /sysroot/composefs with overly permissive modes
and leaking information.
Centralize the directory creation into a new ensure_composefs_dir()
helper in store/mod.rs that explicitly sets mode 0700. Both the
install-time path (repo.rs) and the runtime lazy-init path
(Storage::get_ensure_composefs) now use this single helper.
Also removes #[allow(dead_code)] from COMPOSEFS_MODE since it is now
actively used, and adds a unit test verifying the directory permissions
and idempotency.
Assisted-by: OpenCode (claude-opus-4-6)
Signed-off-by: John Eckersberg jeckersb@redhat.com