-
Notifications
You must be signed in to change notification settings - Fork 305
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
Support mounting /sysroot (and /boot) read-only #1767
Support mounting /sysroot (and /boot) read-only #1767
Conversation
WIP for #1265 |
6ef8928
to
e3e9e90
Compare
035751f
to
e5c5e2b
Compare
e5c5e2b
to
ef722ba
Compare
☔ The latest upstream changes (presumably 3ca1035) made this pull request unmergeable. Please resolve the merge conflicts. |
ef722ba
to
8a39df6
Compare
OK did the trivial rebase 🏄♂️ for this, and was testing out this patch to cosa:
And FCOS goes into emergency mode since |
Toying with
instead. |
dd8b336
to
822b364
Compare
OK, the problem was ordering around
|
822b364
to
6d54ec2
Compare
This is all we need to tell libostree that we support a read-only `/sysroot` and `/boot`. See ostreedev/ostree#1265 PR in ostreedev/ostree#1767
OK, lifting WIP on this! I still need more testing, but it's ready for review. I have a working FCOS with this and:
Including e.g. package layering, etc. |
☔ The latest upstream changes (presumably bdbce9d) made this pull request unmergeable. Please resolve the merge conflicts. |
if (!g_key_file_load_from_file (keyfile, config_path, 0, NULL)) | ||
return false; | ||
|
||
return g_key_file_get_boolean (keyfile, "sysroot", "readonly", NULL); |
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 do we need to introduce a new key here instead of just handling it based on ro
being in /etc/fstab
? IIUC, for FCOS at least, it'll still be rw
at initrd time to avoid the machine-id mess, and then will be re-mounted ro
by systemd right before ostree-remount.service
(though we could still recheck & remount here as we do right now).
Might've missed discussions around this, though keeping the same API as on other traditional systems I think is worth a lot.
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.
As of now, we don't have an /etc/fstab
in FCOS anymore.
The other thing is...we're trying to create a "middle ground" around "read-only". Here the physical root is writable - it has /etc
and /var
by default. Wouldn't you expect having ro
in /etc/fstab
would be truly read-only?
This is really a magical ostree-specific flag I think to opt-in to new behavior for systems builders, not really something admins should see/change directly.
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 other thing is...we're trying to create a "middle ground" around "read-only". Here the physical root is writable - it has /etc and /var by default. Wouldn't you expect having ro in /etc/fstab would be truly read-only?
OK, I follow. Hmm, I think one confusion here is that "read-only root" can mean a lot of things. Particularly /etc
could be interpreted as being covered (and I think it'd be really cool to support this too). I wonder if sysroot.readonly
shouldn't be an enum instead. E.g. none
(status quo), base
(everything except /var
and /etc
) and full
(just /var
is read-write). WDYT? (Not suggesting to implement full
here, just keeping the option open so we leverage the same knob).
6d54ec2
to
38fe770
Compare
38fe770
to
a20bcae
Compare
This is all we need to tell libostree that we support a read-only `/sysroot` and `/boot`. See ostreedev/ostree#1265 PR in ostreedev/ostree#1767
This is all we need to tell libostree that we support a read-only `/sysroot` and `/boot`. See ostreedev/ostree#1265 PR in ostreedev/ostree#1767
This is all we need to tell libostree that we support a read-only `/sysroot` and `/boot`. See ostreedev/ostree#1265 PR in ostreedev/ostree#1767
This is all we need to tell libostree that we support a read-only `/sysroot` and `/boot`. See ostreedev/ostree#1265 PR in ostreedev/ostree#1767
This is all we need to tell libostree that we support a read-only `/sysroot` and `/boot`. See ostreedev/ostree#1265 PR in ostreedev/ostree#1767
This is all we need to tell libostree that we support a read-only `/sysroot` and `/boot`. See ostreedev/ostree#1265 PR in ostreedev/ostree#1767
This is all we need to tell libostree that we support a read-only `/sysroot` and `/boot`. See ostreedev/ostree#1265 PR in ostreedev/ostree#1767
I am seeing this service fail in RHCOS when rebasing ostree to a version that supports ostreedev/ostree#1767 When using `DefaultDependencies=no`, one really wants to specify *some* dependency - very few units have no dependencies at all. In this case, let's run "early" which means after `sysinit.target` but before `basic.target`, which will ensure we run after `ostree-prepare-root.service`.
I am seeing this service fail in RHCOS when rebasing ostree to a version that supports ostreedev/ostree#1767 When using `DefaultDependencies=no`, one really wants to specify *some* dependency - very few units have no dependencies at all. In this case, let's run "early" which means after `sysinit.target` but before `basic.target`, which will ensure we run after `ostree-prepare-root.service`.
I am seeing this service fail in RHCOS when rebasing ostree to a version that supports ostreedev/ostree#1767 When using `DefaultDependencies=no`, one really wants to specify *some* dependency - very few units have no dependencies at all. In this case, let's run "early" which means after `sysinit.target` but before `basic.target`, which will ensure we run after `ostree-prepare-root.service`.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also andd `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
On newer rpm-ostree systems /sysroot can be mounted read-only [1] which means we can't pull commit metadata into the repo. Let's remount it read-write if that's the case. [1] ostreedev/ostree#1767
On newer rpm-ostree systems /sysroot can be mounted read-only [1] which means we can't pull commit metadata into the repo. Let's remount it read-write if that's the case. [1] ostreedev/ostree#1767
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also andd `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also andd `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also andd `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also andd `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also add `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also add `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also add `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
ostree has had support for leaving `/boot` mounted read-only for a long time: ostreedev/ostree#1767 (And then later extended to `/sysroot`) Particularly for CoreOS, only a few things should be touching `/boot`, and we control all of them. Those projects should create a new mount namespace and remount these partitions writable just while they need it. The main thing we're accomplishing here is making the system more resilient against accidental damage from a sysadmin root shell as well as configuration management tools like Puppet/Ansible. None of those should be directly manipulating files on these partitions, they should go through the API of one of our projects (e.g. `rpm-ostree kargs`, `bootupctl`) etc. While we're here, also add `nodev,nosuid` because some OS hardening scanners like to see this. IMO it's of minimal value, but hey, might as well.
Add a magic file and an API for consumers to tell us it's OK
for us to remount read-write (since it'll just affect our
mount namespace).