Page MenuHomeFreeBSD

Fix renameat(2) for CAPABILITIES kernels.
ClosedPublic

Authored by kib on Feb 7 2019, 3:53 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 7, 11:00 AM
Unknown Object (File)
Nov 22 2024, 3:08 PM
Unknown Object (File)
Nov 16 2024, 4:18 AM
Unknown Object (File)
Nov 15 2024, 8:21 PM
Unknown Object (File)
Nov 11 2024, 5:14 PM
Unknown Object (File)
Nov 11 2024, 4:45 PM
Unknown Object (File)
Nov 11 2024, 12:07 PM
Unknown Object (File)
Nov 11 2024, 9:06 AM
Subscribers

Details

Summary

When renameat(2) is used with:

  • absolute path for to;
  • tofd not set to AT_FDCWD
  • the target exists

kern_renameat() requires CAP_UNLINK capability on tofd, but corresponding namei ni_filecap is not initialized at all because the lookup is absolute. As result the check was done against empty filecap and syscall fails erronously.

Fix it by creating a return flags namei member and reporting if the lookup was absolute, then do not touch to.ni_filecaps at all.

PR: 222258
MFC note: this breaks struct namei layout. Do we want the merge ?

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Feb 7 2019, 9:23 PM

Thanks so much!

@emaste: MFC note: this breaks struct namei layout. Do we want the merge ?

Should this field be at the end of the struct to avoid breaking ABI?

In D19096#408759, @ngie wrote:

Thanks so much!

@emaste: MFC note: this breaks struct namei layout. Do we want the merge ?

Should this field be at the end of the struct to avoid breaking ABI?

Moving the new field around would not preserve the KBI. struct namei is typically allocated by the callers on stack.

Still, we do have the tradition of breaking VFS KBI between x.0 and x.1, so I do not see why 12.0 should be an exempt.

This revision was automatically updated to reflect the committed changes.