Fix by @delphij
Currently, if a uid/gid is unknown to the system, zfs(1M) would say nothing on
the unknown user/group. For instance, after a user which owns uid=1002 is
removed, we would have something like this, if 'destroy' is previously granted:
```
$ zfs allow zeta/test
---- Permissions on zeta/test ----------------------------------------
Local+Descendent permissions:
user destroy
```
With the attached patch applied, it would become:
```
$ zfs allow zeta/test
---- Permissions on zeta/test ----------------------------------------
Local+Descendent permissions:
user (unknown: 1002) destroy
```
The proposed patch also allows 'allow' and 'unallow' to accept numerical IDs,
even when they are not known to the system, when -u or -g is explicitly
specified. Without the change there would be no way other than recreating a
user/group that occupies the same UID/GID to revoke a granted permission to
unknown user.
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull/690
-- Commit Summary --
* 6037 zfs(1M) needs to handle unknown uid/gid in context of allow/unallow
more gracefully
-- File Changes --
M usr/src/cmd/zfs/zfs_main.c (18)
-- Patch Links --
https://github.com/openzfs/openzfs/pull/690.patch
https://github.com/openzfs/openzfs/pull/690.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/690
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T64a36645747eec16-Mf550bfa47f17e7043b399e33
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
