Fix filesystem_limit enforcement

[behlendorf]

Motivation and Context

Issue #8226. Observed 'filesystem_limit' behavior differs from that
described in the man page and code.

TODO: Investigate adding test cases for the filesystem_limit feature.

Description

As described in the zfs(8) man page the 'filesystem_limit' does not
apply to users who are allowed to change the property.

This was incorrectly failing because unlike all other operations
the credential was being checked again outside the user context in
the syncing context. Checking the stored user credential in a
different context will always fail on Linux. See the comment above
priv_policy_ns() for details.

The proposed solution is to convert the CRED() to a kcred after the
secpolicy_zfs() checks succeed in the calling context. This allows
the check to be correctly performed a second time in the syncing
context.

To my surprise test cases were apparently never written for this
feature. If there had been some this may have been caught during
the initial port, and we should look in to adding some. For the
moment this change was manually tested.

How Has This Been Tested?

Locally built and manually tested the failure scenario.

[behlendo@centos7]$ sudo zfs create -o filesystem_limit=3 tank/limited
[behlendo@centos7]$ sudo zfs allow -u behlendo create,mount tank/limited
[behlendo@centos7]$ zfs create tank/limited/fs1
[behlendo@centos7]$ zfs create tank/limited/fs2
[behlendo@centos7]$ zfs create tank/limited/fs3
[behlendo@centos7]$ zfs create tank/limited/fs4
cannot create 'tank/limited/fs4': out of space
[behlendo@centos7]$ sudo zfs create tank/limited/fs4
[behlendo@centos7]$ sudo zfs create tank/limited/fs5

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.

[loli10K]

+1 for adding tests, i was investigating #8226 and found another issue with "filesystem_limit" which i am still debugging but was ready to test in a new "group":

diff --git a/tests/runfiles/linux.run b/tests/runfiles/linux.run
index f33a91649..c05225f18 100644
--- a/tests/runfiles/linux.run
+++ b/tests/runfiles/linux.run
@@ -514,6 +514,11 @@ tags = ['functional', 'cp_files']
 tests = ['ctime_001_pos' ]
 tags = ['functional', 'ctime']
 
+[tests/functional/dataset_limits]
+tests = ['filesystem_count', 'filesystem_limit', 'snapshot_count',
+    'snapshot_limit']
+tags = ['functional', 'limits']
+
 [tests/functional/deadman]
 tests = ['deadman_sync', 'deadman_zio']
 pre =

[codecov]

Codecov Report

Merging #8228 into master will decrease coverage by 0.05%.
The diff coverage is 87.5%.

@@            Coverage Diff             @@
##           master    #8228      +/-   ##
==========================================
- Coverage   78.56%   78.51%   -0.06%     
==========================================
  Files         379      379              
  Lines      114909   114904       -5     
==========================================
- Hits        90284    90215      -69     
- Misses      24625    24689      +64

Flag	Coverage Δ
#kernel	79.02% <87.5%> (+0.05%)	⬆️
#user	67.45% <75%> (-0.04%)	⬇️

---

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 06f3fc2...3e5b342. Read the comment docs.

[behlendorf]

@loli10K since it sounds like you've been looking in to this, and have already written some tests would you mind taking over this PR too. Based on the test runs we had two unexpected failure which need to explained, and we might want to take a slightly more targeted approach than the one suggested here.

    FAIL delegate/zfs_allow_005_pos (expected PASS)
    FAIL delegate/zfs_unallow_005_pos (expected PASS)

[loli10K]

@behlendorf i am probably a long way from being able to properly fix #8226, the "allow" code is somewhat new to me. I don't mind taking a stab at this though, seems like a good opportunity to study more ZFS code.

The other issue i found is very similar to https://www.illumos.org/issues/6254 and hopefully i should be able to have a working fix this upcoming weekend.

[loli10K]

Alternative version is #8280