Unshare fix for boot.automount

[Johan-Liebert1]

Pass --propagation=slave so that if systemd gpt-auto-generator has
automount for /boot it gets propagated inside the new mount ns
for us to be able to access the /boot mount even if it's expired

Without this all bootc commands fail with

error: Initializing storage: opendir(boot): Operation not permitted

Closes: #2402

[cgwalters]

I don't understand how this would fix the bug; isn't the root problem that we have dueling/conflicting generators for /boot?

Is the default propagation here private? And so by making it slave...if something mounts /boot in the outer mountns it mounts it for us? We almost certainly want slave semantics anyways, so this seems like a good idea.

But what would trigger the mount in the default mountns?

I don't understand how this fixes the bug.

[Johan-Liebert1]

Is the default propagation here private?

yes, the default is private.

I believe the issue is with private mount namespace, the mount request is not actually sent to systemd and thus the automount is not performed. Following journalctl logs

# Tried to access /boot on PID1 mounts 

Aug 26 12:25:09 fedora systemd[1]: boot.automount: Got automount request for /boot, triggered by 1513 (bash)                                                                                   
Aug 26 12:25:09 fedora systemd[1]: Mounting boot.mount - /boot...                                                                                                                              
Aug 26 12:25:09 fedora systemd[1]: Mounted boot.mount - /boot.                                                                                                                                 
                                                                                                                                                                                               
                                                                                                                                                                                               
# boot.automount Unmounts /boot as I have a timer of 2 seconds
                                                                                                                                
Aug 26 12:25:19 fedora systemd[1]: Unmounting boot.mount - /boot...                                                                                                                            
Aug 26 12:25:19 fedora systemd[1]: boot.mount: Deactivated successfully.                                                                                                                       
Aug 26 12:25:19 fedora systemd[1]: Unmounted boot.mount - /boot.  

1. Ran `unshare -m /bin/bash; cd /boot` 

No logs appear as automount request was not sent to systemd

[Johan-Liebert1]

And so by making it slave...if something mounts /boot in the outer mountns it mounts it for us?

Currently (with private ns), no. Since our mount ns is private, we don't see outer mounts done after unsharing and they don't see ours

With slave mount ns, we do get mounts from outer mount ns, though they don't see ours iirc. For mounts to propagate both ways, we need propagation=shared I think

[cgwalters]

Hmm...okay after digging in a bit more, I think using slave propagation is almost always the right thing to do for use cases like ours; as the docs say otherwise things like e.g. plugging in a USB stick wouldn't be visible. But of course since we're not a daemon, in practice it mostly doesn't matter.

So I think this change is right on the face of it, but I don't think it's a complete fix since I think we still have dueling /boot going on. But, that's actually more of an ostree side bug.

[cgwalters]

Hardcoded sleeps invite race conditions, most of these should be edge triggered or at least polling loops with a timeout.

In this case I'm pretty sure we can monitor for changes in the unit via the dbus api.