overlay: drop check for mount_program AND force_mask

[giuseppe]

Using a mount_program is not a necessary requirement for users creating a shared store, as the store can be consumed by other users.

Stop enforcing this rule.

[rhatdan]

LGTM
@saschagrunert @mtrmac @nalind PTAL

[mtrmac]

Probably best if someone else reviews this…

---

Using a mount_program is not a necessary requirement for users creating a shared store, as the store can be consumed by other users.

I don’t understand how “shared store” and “mount_program” interact.

It seems to me that when creating a layer applying a diff, we can set the permissions ourselves while untarring. Fine.

What happens with read-write layers? AFAICS in that case we really need the filesystem driver (in-kernel or FUSE) to enforce the mask … but I also see nothing that passes the value to the mount operation.

So I don’t understand how any of this works even before this PR, and I’m just confused.

[giuseppe]

What happens with read-write layers? AFAICS in that case we really need the filesystem driver (in-kernel or FUSE) to enforce the mask … but I also see nothing that passes the value to the mount operation.

yes a mount_program is still needed if you plan to use that same store, the issue though is that we require a mount_program even if the root user is not going to use that store to run containers, but only to share images to different users. The store can be made available also on a network file system, so users are not necessarily on the same machine. So we either require fuse-overlayfs to be installed, or provide a workaround with a dummy mount_program, since it doesn't matter when we pull an image.

[mtrmac]

Would it make sense to refuse to create RW layers if force_mask is used without mount_program, then? (I don’t see how that actually works, I don’t know what I’m saying…)

[giuseppe]

Would it make sense to refuse to create RW layers if force_mask is used without mount_program, then? (I don’t see how that actually works, I don’t know what I’m saying…)

sure we can do that. Added a check and submitted a new version

[cgwalters]

Don't know this code really well, but looks sane to me
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters, giuseppe

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:

• OWNERS [giuseppe]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mtrmac]

LGTM?

I don’t see how RW layers work with force_mask at all, but this is is at least not inconsistent with how I imagine it might be working :)

(I plan to leave this for 2 days, to give knowledgeable reviewers an opportunity, and then I default to merging.)

[mtrmac]

/lgtm

as I threatened.