-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Property filesystem_limit does not work as documented #8226
Labels
Type: Defect
Incorrect behavior (e.g. crash, hang)
Comments
for me it looks like it was fixed !? close? |
This is not fixed:
|
The test for this is also wrong. |
ghost
pushed a commit
to zfsonfreebsd/ZoF
that referenced
this issue
Feb 29, 2020
See issue openzfs#8226: Property filesystem_limit does not work as documented There have been previous attempts to fix the behavior on Linux, but so far the issue is still open. See PRs openzfs#8228, openzfs#8280. The existing tests pass for the incorrect behavior. This is a problem on FreeBSD; we are failing the tests because we implement the feature correctly. I have adapted the tests based on the work by @loli10K in openzfs#8280 and extended the changes to fix the snapshot_limit test as well. Linux now fails these tests, so entries linking to the issue have been added to the "maybe" group in zts-report.py. Signed-off-by: Ryan Moeller <ryan@iXsystems.com>
12 tasks
ghost
pushed a commit
to zfsonfreebsd/ZoF
that referenced
this issue
Feb 29, 2020
See issue openzfs#8226: Property filesystem_limit does not work as documented There have been previous attempts to fix the behavior on Linux, but so far the issue is still open. See PRs openzfs#8228, openzfs#8280. The existing tests pass for the incorrect behavior. This is a problem on FreeBSD; we are failing the tests because we implement the feature correctly. I have adapted the tests based on the work by @loli10K in openzfs#8280 and extended the changes to fix the snapshot_limit test as well. Linux now fails these tests, so entries linking to the issue have been added to the "maybe" group in zts-report.py. Signed-off-by: Ryan Moeller <ryan@iXsystems.com>
behlendorf
added a commit
that referenced
this issue
Mar 4, 2020
See issue #8226: Property filesystem_limit does not work as documented There have been previous attempts to fix the behavior on Linux, but so far the issue is still open. See PRs #8228, #8280. The existing tests pass for the incorrect behavior. This is a problem on FreeBSD; we are failing the tests because we implement the feature correctly. I have adapted the tests based on the work by @loli10K in #8280 and extended the changes to fix the snapshot_limit test as well. Linux now fails these tests, so entries linking to the issue have been added to the "maybe" group in zts-report.py. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Ryan Moeller <ryan@iXsystems.com> Closes #10082
ahrens
added a commit
to ahrens/zfs
that referenced
this issue
Jul 8, 2020
The filesystem_limit and snapshot_limit properties limit the number of filesystems or snapshots that can be created below this dataset. According to the manpage, "The limit is not enforced if the user is allowed to change the limit." Two types of users are allowed to change the limit: 1. Those that have been delegated the `filesystem_limit` or `snapshot_limit` permission, e.g. with `zfs allow USER filesystem_limit DATASET`. This works properly. 2. A user with elevated system priviliges (e.g. root). This does not work - the root user will incorrectly get an error when trying to create a snapshot/filesystem, if it exceeds the `_limit` property. The problem is that `priv_policy_ns()` does not work if the `cred_t` is not that of the current process. This happens when `dsl_enforce_ds_ss_limits()` is called in syncing context (as part of a sync task's check func) to determine the permissions of the corresponding user process. This commit fixes the issue by passing the `task_struct` (typedef'ed as a `proc_t`) to syncing context, and then using `has_capability()` to determine if that process is privileged. Note that we still need to pass the `cred_t` to syncing context so that we can check if the user was delegated this permission with `zfs allow`. This problem only impacts Linux. Wrappers are added to FreeBSD but it continues to use `priv_check_cred()`, which works on arbitrary `cred_t`. Signed-off-by: Matthew Ahrens <mahrens@delphix.com> Closes: openzfs#8226
12 tasks
behlendorf
pushed a commit
that referenced
this issue
Jul 12, 2020
The filesystem_limit and snapshot_limit properties limit the number of filesystems or snapshots that can be created below this dataset. According to the manpage, "The limit is not enforced if the user is allowed to change the limit." Two types of users are allowed to change the limit: 1. Those that have been delegated the `filesystem_limit` or `snapshot_limit` permission, e.g. with `zfs allow USER filesystem_limit DATASET`. This works properly. 2. A user with elevated system privileges (e.g. root). This does not work - the root user will incorrectly get an error when trying to create a snapshot/filesystem, if it exceeds the `_limit` property. The problem is that `priv_policy_ns()` does not work if the `cred_t` is not that of the current process. This happens when `dsl_enforce_ds_ss_limits()` is called in syncing context (as part of a sync task's check func) to determine the permissions of the corresponding user process. This commit fixes the issue by passing the `task_struct` (typedef'ed as a `proc_t`) to syncing context, and then using `has_capability()` to determine if that process is privileged. Note that we still need to pass the `cred_t` to syncing context so that we can check if the user was delegated this permission with `zfs allow`. This problem only impacts Linux. Wrappers are added to FreeBSD but it continues to use `priv_check_cred()`, which works on arbitrary `cred_t`. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Ryan Moeller <ryan@ixsystems.com> Signed-off-by: Matthew Ahrens <mahrens@delphix.com> Closes #8226 Closes #10545
jsai20
pushed a commit
to jsai20/zfs
that referenced
this issue
Mar 30, 2021
See issue openzfs#8226: Property filesystem_limit does not work as documented There have been previous attempts to fix the behavior on Linux, but so far the issue is still open. See PRs openzfs#8228, openzfs#8280. The existing tests pass for the incorrect behavior. This is a problem on FreeBSD; we are failing the tests because we implement the feature correctly. I have adapted the tests based on the work by @loli10K in openzfs#8280 and extended the changes to fix the snapshot_limit test as well. Linux now fails these tests, so entries linking to the issue have been added to the "maybe" group in zts-report.py. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Ryan Moeller <ryan@iXsystems.com> Closes openzfs#10082
jsai20
pushed a commit
to jsai20/zfs
that referenced
this issue
Mar 30, 2021
The filesystem_limit and snapshot_limit properties limit the number of filesystems or snapshots that can be created below this dataset. According to the manpage, "The limit is not enforced if the user is allowed to change the limit." Two types of users are allowed to change the limit: 1. Those that have been delegated the `filesystem_limit` or `snapshot_limit` permission, e.g. with `zfs allow USER filesystem_limit DATASET`. This works properly. 2. A user with elevated system privileges (e.g. root). This does not work - the root user will incorrectly get an error when trying to create a snapshot/filesystem, if it exceeds the `_limit` property. The problem is that `priv_policy_ns()` does not work if the `cred_t` is not that of the current process. This happens when `dsl_enforce_ds_ss_limits()` is called in syncing context (as part of a sync task's check func) to determine the permissions of the corresponding user process. This commit fixes the issue by passing the `task_struct` (typedef'ed as a `proc_t`) to syncing context, and then using `has_capability()` to determine if that process is privileged. Note that we still need to pass the `cred_t` to syncing context so that we can check if the user was delegated this permission with `zfs allow`. This problem only impacts Linux. Wrappers are added to FreeBSD but it continues to use `priv_check_cred()`, which works on arbitrary `cred_t`. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Ryan Moeller <ryan@ixsystems.com> Signed-off-by: Matthew Ahrens <mahrens@delphix.com> Closes openzfs#8226 Closes openzfs#10545
sempervictus
pushed a commit
to sempervictus/zfs
that referenced
this issue
May 31, 2021
The filesystem_limit and snapshot_limit properties limit the number of filesystems or snapshots that can be created below this dataset. According to the manpage, "The limit is not enforced if the user is allowed to change the limit." Two types of users are allowed to change the limit: 1. Those that have been delegated the `filesystem_limit` or `snapshot_limit` permission, e.g. with `zfs allow USER filesystem_limit DATASET`. This works properly. 2. A user with elevated system privileges (e.g. root). This does not work - the root user will incorrectly get an error when trying to create a snapshot/filesystem, if it exceeds the `_limit` property. The problem is that `priv_policy_ns()` does not work if the `cred_t` is not that of the current process. This happens when `dsl_enforce_ds_ss_limits()` is called in syncing context (as part of a sync task's check func) to determine the permissions of the corresponding user process. This commit fixes the issue by passing the `task_struct` (typedef'ed as a `proc_t`) to syncing context, and then using `has_capability()` to determine if that process is privileged. Note that we still need to pass the `cred_t` to syncing context so that we can check if the user was delegated this permission with `zfs allow`. This problem only impacts Linux. Wrappers are added to FreeBSD but it continues to use `priv_check_cred()`, which works on arbitrary `cred_t`. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Ryan Moeller <ryan@ixsystems.com> Signed-off-by: Matthew Ahrens <mahrens@delphix.com> Closes openzfs#8226 Closes openzfs#10545
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System information
Describe the problem you're observing
According to the zfs manual
filesystem_limit
does not apply to users allowed to change the property:I find this information to be wrong.
Describe how to reproduce the problem
Include any warning/errors/backtraces from the system logs
None
The text was updated successfully, but these errors were encountered: