Repository navigation
context: Keep fallback-x11 separate from x11 conditionals - #6632
Conversation
2fdba55 to
dc5af82
Compare
|
This seems better to me than trying to canonicalise too eagerly, too early and loosing context, but I don't have the context of why this was rejected in the initial version. This seems to also solve #5789 |
|
Sigh. I think this is fine. I was just hoping we could have a new modern conditional system and model the old semantics in it. But, as it turns out that just isn't possible, and we don't want to break existing behaviour (even if I think it is weird). So, this looks good to me. |
|
And, to be more precise, when I say it is weird, what I mean is that when originally fallback-x11 was added, it also set x11 so that older versions of flatpak that didn't understand fallback-x11 would not break. This means that if you have no socket access, and then request fallback-x11 you will get both x11, and fallback-x11. Then, in an override if you !fallback-x11 this now gives you just x11, which was never explicitly requested. But, if that is the old behaviour, we unfortunately need to keep it. |
If we convert fallback-x11 internally to a conditional x11 permission, we cannot express current fallback-x11 stacking behavior: lower: empty + upper: !fallback-x11 -> no x11 access lower: fallback-x11 + upper: !fallback-x11 -> x11 access The reason is that conditionals have no view of the lower level. This changes things in a way that fallback-x11 stays its own socket permission with two interactions with the x11 socket permission: * If a upper level resets x11 (--socket=x11, --nosocket=x11), the lower level fallback-x11 permission gets dropped * When computing the allowed sockets, --socket=fallback-x11 gets converted to --socket=if:x11:!has-wayland Fixes: flatpak#6556
dc5af82 to
385e969
Compare
|
fwiw, i would have preferred if the original implementation rejected, fallback-x11, or !fallback-x11 because on their own, they don't have much meaning and it's hard to justify attaching meaning to them. I would have also preferred if flatseal etc. wrote what flatpak-override --nosocket writes instead of naively writing !fallback-x11. |
3 participants
Another attempt. This is similar to what I had at a previous point, but @alexlarsson wasn't happy with it.