Fix get_special_prop() build failure

[behlendorf]

Motivation and Context

Build failure observed in #8999.

Description

The cast of the size_t returned by strlcpy() to a uint64_t by the
VERIFY3U can result in a build failure when CONFIG_FORTIFY_SOURCE
is set. This is due to the additional hardening. Since the token
will always fit in strval the VERIFY3U has been removed.

How Has This Been Tested?

Locally compiled and tested #8999 (comment)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.

[codecov]

Codecov Report

Merging #9020 into master will decrease coverage by 0.09%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #9020     +/-   ##
=========================================
- Coverage   78.66%   78.56%   -0.1%     
=========================================
  Files         401      401             
  Lines      120146   120146             
=========================================
- Hits        94514    94396    -118     
- Misses      25632    25750    +118

Flag	Coverage Δ
#kernel	79.45% <100%> (+0.02%)	⬆️
#user	66.34% <0%> (-0.26%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d230a65...b32ad91. Read the comment docs.

[tonyhutter]

Since the token will always fit in strval the VERIFY3U has been removed.

I looked at get_receive_resume_stats_impl() to see what token's size could be, but it wasn't clear. How do you know it will always fit in strval?

[behlendorf]

Technically you're right, we don't have a known hard maximum bound. The token is constructed from a compressed-packed nvlist that is generated, and we happen to know that the nvlist will be relatively small (since we constructed the nvlist). In practice the tokenized ascii version of it is around 200-300 bytes. A lot of redacted snapshots or bookmarks look like they could inflate that a little.

We've also got a lot of headroom here the buffer being allocated is 8192 byte so ~20x what we need. And if we were somehow able to generate a token that large, the worst case would be that a truncated token was returned.

That all said, you may be right there's no good reason not to check for the truncation here and return EOVERFLOW which should bubble up as a fatal lua error when getting properties. And not a truncated token.