Skip to content
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

Fix mount propagation #85

Conversation

valentindavid
Copy link
Collaborator

To switch root, systemd has to recursively make all mounts private, then after it recursively make all mounts shared.

However /run/mnt/* and /writable are used to be bind mounted in the rest of the file system. For example, there is no reason for mount /snap/hello/42 to also show up as
/writable/system-data/snap/hello/42 and
/run/mnt/data/system-data/snap/hello/42.

To switch root, systemd has to recursively make all mounts private,
then after it recursively make all mounts shared.

However `/run/mnt/*` and `/writable` are used to be bind mounted in
the rest of the file system. For example, there is no reason for mount
`/snap/hello/42` to also show up as
`/writable/system-data/snap/hello/42` and
`/run/mnt/data/system-data/snap/hello/42`.
@valentindavid
Copy link
Collaborator Author

None of these path with be available in /var/lib/snapd/hostfs. But I think they are already not accessible.

Copy link
Member

@alfonsosanchezbeato alfonsosanchezbeato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor comments. FTR I have checked and /var/lib/snapd/hostfs/writable is empty in confined snaps and there is something in /var/lib/snapd/hostfs/run/mnt/data/system-data/snap, but just directories and symbolic links, so we should be safe for backwards compatibility there. Also, no interface gives access there at first sight.

RemainAfterExit=yes
ExecStart=/usr/lib/core/remount-core-fs

[Install]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Install section is not needed and it looks like in general we don't add it unless it is the case.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know. I am not sure how I feel about the way we do it. We put everything in /usr/lib/systemd because /etc/systemd/system is writable. But we can always symlink to /dev/null in /etc to mask services installed in /usr. So the reason we use /usr/lib/systemd does not completely work.

I have added the Install section as indication of where it is expected to be installed. And in that way, we could one day move to another approach than what we are doing.

I can remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually prefer it to stay as I agree it is better to have it as a hint on where the service is expected. But then we should enforce it in next changes as good practice.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have created #86 so we only use install sections and generate the symlinks.

Description=Reset propagation of initial mount points
DefaultDependencies=no
Before=local-fs-pre.target
Before=local-fs.target
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this needed? local-fs-pre.target is expected to happen before afaiu.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in case something happens with local-fs-pre.target, like something making it fail.

Note that I used roughly the same dependencies as systemd-remount-fs.service.

Before=local-fs-pre.target
Before=local-fs.target
Before=shutdown.target
Wants=local-fs-pre.target
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

local-fs-pre.target is pulled already by local-fs.target

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. It only has After=. Typically the -pre targets are only added if needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks

Copy link
Member

@alfonsosanchezbeato alfonsosanchezbeato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks

I have tested and this makes a difference for /writable/system-data/snap/, where mounted snap files are not seen anymore. /run/mnt/data/system-data/snap/ did not actually seem to have the issue though.

RemainAfterExit=yes
ExecStart=/usr/lib/core/remount-core-fs

[Install]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually prefer it to stay as I agree it is better to have it as a hint on where the service is expected. But then we should enforce it in next changes as good practice.

Before=local-fs-pre.target
Before=local-fs.target
Before=shutdown.target
Wants=local-fs-pre.target
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks

@alfonsosanchezbeato alfonsosanchezbeato merged commit 3f52445 into canonical:main Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants