Page MenuHomeFreeBSD

unionfs: workaround underlying FS failing to respect cn_namelen
ClosedPublic

Authored by jah on Feb 10 2024, 4:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 30, 5:20 AM
Unknown Object (File)
Fri, Oct 25, 5:34 PM
Unknown Object (File)
Fri, Oct 25, 5:33 PM
Unknown Object (File)
Mon, Oct 21, 1:38 AM
Unknown Object (File)
Mon, Oct 21, 12:09 AM
Unknown Object (File)
Fri, Oct 18, 6:59 PM
Unknown Object (File)
Sep 21 2024, 2:48 AM
Unknown Object (File)
Sep 17 2024, 7:05 PM
Subscribers

Details

Summary

unionfs_mkshadowdir() may be invoked on a non-leaf pathname component
during lookup, in which case the NUL terminator of the pathname buffer
will be well beyond the end of the current component. cn_namelen in
this case will still (correctly) indicate the length of only the
current component, but ZFS in particular does not currently respect
cn_namelen, leading to the creation on inacessible files with slashes
in their names. Work around this behavior by temporarily NUL-
terminating the current pathname component for the call to VOP_MKDIR().

PR: 275871
Reported by: Karlo Miličević <karlo98.m@gmail.com>
Tested by: Karlo Miličević <karlo98.m@gmail.com>
MFC after: 2 weeks

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 55931
Build 52820: arc lint + arc unit

Event Timeline

jah requested review of this revision.Feb 10 2024, 4:49 PM

Also filed https://github.com/openzfs/zfs/issues/15705, as I think that would benefit OpenZFS as well.

jah planned changes to this revision.Feb 11 2024, 5:27 AM

Putting this on hold, as I'm evaluating a less-hacky approach.

jah requested review of this revision.Feb 11 2024, 6:56 AM

Sadly my attempt at something less hacky didn't really improve things.

This revision is now accepted and ready to land.Feb 11 2024, 7:12 AM

OK as a workaround. Hopefully, we'll get OpenZFS fixed soon. If you don't plan to, I may try to submit a patch upstream, since it seems no one has proposed any change in https://github.com/openzfs/zfs/issues/15705.

In D43818#999955, @olce wrote:

OK as a workaround. Hopefully, we'll get OpenZFS fixed soon. If you don't plan to, I may try to submit a patch upstream, since it seems no one has proposed any change in https://github.com/openzfs/zfs/issues/15705.

Actually I've been thinking of doing exactly that, although it depends on how much time I get away from $work over the next few weeks. But that does remind me: speaking of things we'd both like to see, what do you want to do about https://reviews.freebsd.org/D40850 and the constellation of associated changes? I just gave that review a kick.

In D43818#1000015, @jah wrote:

Actually I've been thinking of doing exactly that, although it depends on how much time I get away from $work over the next few weeks.

I just wanted to make sure that someone was going to push a solution upstream so that we don't stay with such workarounds for ages. So, great (and I don't need to intervene).

But that does remind me: speaking of things we'd both like to see, what do you want to do about https://reviews.freebsd.org/D40850 and the constellation of associated changes? I just gave that review a kick.

Answered there.

Thanks.