WIP: systemd: Toggle on ProtectHome=true #2060
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We might as well make use of this. I thought of this while reviewing coreos/fedora-coreos-config#344
|
/lgtm |
|
Ooh yes exciting, this breaks livefs... I suspect it's because we're running But more generally...only way this is going to be sane is if we split the livefs bits out into a separate unit like |
cgwalters
changed the title
|
/lgtm cancel |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jlebon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Apr 22, 2020
Same motivation as coreos/rpm-ostree#2060 I tried `InaccessiblePaths=/var` first and was very sad to find out we have one tiny exception that breaks it. Otherwise it'd be so elegant. Maybe in the future we split out that one thing to a separate `ostree-finalized-stage-var.service` that's just `ExecStart=/bin/rm -vf /var/.updated` and is otherwise `ProtectSystem=strict` etc.
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Apr 22, 2020
Same motivation as coreos/rpm-ostree#2060 I tried `InaccessiblePaths=/var` first and was very sad to find out we have one tiny exception that breaks it. Otherwise it'd be so elegant. Maybe in the future we split out that one thing to a separate `ostree-finalized-stage-var.service` that's just `ExecStart=/bin/rm -vf /var/.updated` and is otherwise `ProtectSystem=strict` etc.
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
May 17, 2020
I was thinking a bit more recently about the "live" changes stuff coreos/rpm-ostree#639 (particularly since coreos/rpm-ostree#2060 ) and I realized reading the last debates in that issue that there's really a much simpler solution; do exactly the same thing we do for `ostree admin unlock`, except mount it read-only by default. Then, anything that wants to modify it does the same thing libostree does for `/sysroot` and `/boot` as of recently; create a new mount namespace and do the modifications there. The advantages of this are numerous. First, we already have all of the code, it's basically just plumbing through a new entry in the state enumeration and passing `MS_RDONLY` into the `mount()` system call. "live" changes here also naturally don't persist, unlike what we are currently doing in rpm-ostree.
agners
pushed a commit
to agners/ostree
that referenced
this pull request
May 29, 2020
Same motivation as coreos/rpm-ostree#2060 I tried `InaccessiblePaths=/var` first and was very sad to find out we have one tiny exception that breaks it. Otherwise it'd be so elegant. Maybe in the future we split out that one thing to a separate `ostree-finalized-stage-var.service` that's just `ExecStart=/bin/rm -vf /var/.updated` and is otherwise `ProtectSystem=strict` etc.
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Jun 3, 2020
I was thinking a bit more recently about the "live" changes stuff coreos/rpm-ostree#639 (particularly since coreos/rpm-ostree#2060 ) and I realized reading the last debates in that issue that there's really a much simpler solution; do exactly the same thing we do for `ostree admin unlock`, except mount it read-only by default. Then, anything that wants to modify it does the same thing libostree does for `/sysroot` and `/boot` as of recently; create a new mount namespace and do the modifications there. The advantages of this are numerous. First, we already have all of the code, it's basically just plumbing through a new entry in the state enumeration and passing `MS_RDONLY` into the `mount()` system call. "live" changes here also naturally don't persist, unlike what we are currently doing in rpm-ostree.
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Aug 5, 2020
I was thinking a bit more recently about the "live" changes stuff coreos/rpm-ostree#639 (particularly since coreos/rpm-ostree#2060 ) and I realized reading the last debates in that issue that there's really a much simpler solution; do exactly the same thing we do for `ostree admin unlock`, except mount it read-only by default. Then, anything that wants to modify it does the same thing libostree does for `/sysroot` and `/boot` as of recently; create a new mount namespace and do the modifications there. The advantages of this are numerous. First, we already have all of the code, it's basically just plumbing through a new entry in the state enumeration and passing `MS_RDONLY` into the `mount()` system call. "live" changes here also naturally don't persist, unlike what we are currently doing in rpm-ostree.
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Aug 5, 2020
I was thinking a bit more recently about the "live" changes stuff coreos/rpm-ostree#639 (particularly since coreos/rpm-ostree#2060 ) and I realized reading the last debates in that issue that there's really a much simpler solution; do exactly the same thing we do for `ostree admin unlock`, except mount it read-only by default. Then, anything that wants to modify it does the same thing libostree does for `/sysroot` and `/boot` as of recently; create a new mount namespace and do the modifications there. The advantages of this are numerous. First, we already have all of the code, it's basically just plumbing through a new entry in the state enumeration and passing `MS_RDONLY` into the `mount()` system call. "live" changes here also naturally don't persist, unlike what we are currently doing in rpm-ostree.
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Aug 7, 2020
I was thinking a bit more recently about the "live" changes stuff coreos/rpm-ostree#639 (particularly since coreos/rpm-ostree#2060 ) and I realized reading the last debates in that issue that there's really a much simpler solution; do exactly the same thing we do for `ostree admin unlock`, except mount it read-only by default. Then, anything that wants to modify it does the same thing libostree does for `/sysroot` and `/boot` as of recently; create a new mount namespace and do the modifications there. The advantages of this are numerous. First, we already have all of the code, it's basically just plumbing through a new entry in the state enumeration and passing `MS_RDONLY` into the `mount()` system call. "live" changes here also naturally don't persist, unlike what we are currently doing in rpm-ostree.
|
Merged into #2293 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We might as well make use of this. I thought of this while
reviewing coreos/fedora-coreos-config#344