On Mon, Jun 02, 2025 at 05:10:21PM -0700, Song Liu wrote: > On Mon, Jun 2, 2025 at 6:36 AM Song Liu <song@xxxxxxxxxx> wrote: > > > > On Sat, May 31, 2025 at 6:51 AM Tingmao Wang <m@xxxxxxxxxx> wrote: > > [...] > > > I'm not sure if the original behavior was intentional, but since this > > > technically counts as a functional changes, just pointing this out. > > > > Thanks for pointing it out! I think it is possible to keep current > > behavior. Or we can change the behavior and state that clearly > > in the commit log. Mickaël, WDYT? > > > > > > > > Also I'm slightly worried about the performance overhead of doing > > > path_connected for every hop in the iteration (but ultimately it's > > > Mickaël's call). At least for Landlock, I think if we want to block all > > > > Maybe we need a flag to path_parent (or path_walk_parent) so > > that we only check for path_connected when necessary. > > More thoughts on path_connected(). I think it makes sense for > path_parent (or path_walk_parent) to continue walking > with path_connected() == false. This is because for most security > use cases, it makes sense for umounted bind mount to fall back > to the permissions of the original mount OTOH, it also makes sense > for follow_dotdot to reject this access at path lookup time. If the > user of path_walk_parent decided to stop walking at disconnected > path, another check can be added at the caller side. I agree. > > If there are no objections, I will remove the path_connected check > from path_walk_parent(). Sounds good. The documentation should explain this rationale and highlight the differences with follow_dotdot(). > > Thanks, > Song >
