-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
zfs_delegate_admin: fix: zfs allow cannot parse unknown uid/gid #5943
zfs_delegate_admin: fix: zfs allow cannot parse unknown uid/gid #5943
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution. Could you please add a changelog fragment and adjust the spacing after commas? Thanks.
When setting allow permissions for particular users or groups there will be circumstances when that user is not known to the host system. In that case the output of `zfs allow <pool/dataset>` looks similar to this: $ sudo zfs allow tank/test ---- Permissions on tank/test --------------------------------------- Local+Descendent permissions: user (unknown: 1002) hold user zfsuser receive The fix in this commit removes ' (unknown: '+')' from the output leaving only the uid/gid. This allows the current parser to continue even if the uid/gid is not known. This situation occurs most often when moving a zpool from one system to another that may not have the same users/groups. Simply adding permissions to a user/group and then deleting the user/group from the system will cause this situation to occur.
4a9b693
to
ecdb7c2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If nobody objects, I'll merge this by this weekend for the next release.
Backport to stable-5: 💚 backport PR created✅ Backport PR branch: Backported as #6085 🤖 @patchback |
When setting allow permissions for particular users or groups there will be circumstances when that user is not known to the host system. In that case the output of `zfs allow <pool/dataset>` looks similar to this: $ sudo zfs allow tank/test ---- Permissions on tank/test --------------------------------------- Local+Descendent permissions: user (unknown: 1002) hold user zfsuser receive The fix in this commit removes ' (unknown: '+')' from the output leaving only the uid/gid. This allows the current parser to continue even if the uid/gid is not known. This situation occurs most often when moving a zpool from one system to another that may not have the same users/groups. Simply adding permissions to a user/group and then deleting the user/group from the system will cause this situation to occur. (cherry picked from commit 53f7297)
Backport to stable-6: 💚 backport PR created✅ Backport PR branch: Backported as #6086 🤖 @patchback |
@papamoose thank you very much for your contribution! |
When setting allow permissions for particular users or groups there will be circumstances when that user is not known to the host system. In that case the output of `zfs allow <pool/dataset>` looks similar to this: $ sudo zfs allow tank/test ---- Permissions on tank/test --------------------------------------- Local+Descendent permissions: user (unknown: 1002) hold user zfsuser receive The fix in this commit removes ' (unknown: '+')' from the output leaving only the uid/gid. This allows the current parser to continue even if the uid/gid is not known. This situation occurs most often when moving a zpool from one system to another that may not have the same users/groups. Simply adding permissions to a user/group and then deleting the user/group from the system will cause this situation to occur. (cherry picked from commit 53f7297)
…llow cannot parse unknown uid/gid (#6086) zfs_delegate_admin: fix: zfs allow cannot parse unknown uid/gid (#5943) When setting allow permissions for particular users or groups there will be circumstances when that user is not known to the host system. In that case the output of `zfs allow <pool/dataset>` looks similar to this: $ sudo zfs allow tank/test ---- Permissions on tank/test --------------------------------------- Local+Descendent permissions: user (unknown: 1002) hold user zfsuser receive The fix in this commit removes ' (unknown: '+')' from the output leaving only the uid/gid. This allows the current parser to continue even if the uid/gid is not known. This situation occurs most often when moving a zpool from one system to another that may not have the same users/groups. Simply adding permissions to a user/group and then deleting the user/group from the system will cause this situation to occur. (cherry picked from commit 53f7297) Co-authored-by: Phil Kauffman <philip@kauffman.me>
…llow cannot parse unknown uid/gid (#6085) zfs_delegate_admin: fix: zfs allow cannot parse unknown uid/gid (#5943) When setting allow permissions for particular users or groups there will be circumstances when that user is not known to the host system. In that case the output of `zfs allow <pool/dataset>` looks similar to this: $ sudo zfs allow tank/test ---- Permissions on tank/test --------------------------------------- Local+Descendent permissions: user (unknown: 1002) hold user zfsuser receive The fix in this commit removes ' (unknown: '+')' from the output leaving only the uid/gid. This allows the current parser to continue even if the uid/gid is not known. This situation occurs most often when moving a zpool from one system to another that may not have the same users/groups. Simply adding permissions to a user/group and then deleting the user/group from the system will cause this situation to occur. (cherry picked from commit 53f7297) Co-authored-by: Phil Kauffman <philip@kauffman.me>
Docs Build 📝Thank you for contribution!✨ This PR has been merged and your docs changes will be incorporated when they are next published. |
…ble-collections#5943) When setting allow permissions for particular users or groups there will be circumstances when that user is not known to the host system. In that case the output of `zfs allow <pool/dataset>` looks similar to this: $ sudo zfs allow tank/test ---- Permissions on tank/test --------------------------------------- Local+Descendent permissions: user (unknown: 1002) hold user zfsuser receive The fix in this commit removes ' (unknown: '+')' from the output leaving only the uid/gid. This allows the current parser to continue even if the uid/gid is not known. This situation occurs most often when moving a zpool from one system to another that may not have the same users/groups. Simply adding permissions to a user/group and then deleting the user/group from the system will cause this situation to occur.
When setting allow permissions for particular users or groups there will be circumstances when that user is not known to the host system.
In that case the output of
zfs allow <pool/dataset>
looks similar to this:$ sudo zfs allow tank/test
---- Permissions on tank/test ---------------------------------------
Local+Descendent permissions:
user (unknown: 1002) hold
user zfsuser receive
The fix in this commit removes
(unknown:
+)
from the output leaving only the uid/gid.This allows the current parser to continue even if the uid/gid is not known.
This situation occurs most often when moving a zpool from one system to another that may not have the same users/groups. Simply adding permissions to a user/group and then deleting the user/group from the system will cause this situation to occur.
SUMMARY
Fixes #5941
Removing
(unknown:
+)
fromline
allows the user to remove and permissions to uids or gids even if the host system is unaware of an actual user/group by that name.Ideally, openzfs could modify the
zfs allow
command to allow for machine readable output like most of the zfs commands available: e.g.-H -o name,permissions,entity
.ISSUE TYPE
COMPONENT NAME
community.general.zfs_delegate_admin
ADDITIONAL INFORMATION
Testing