6037 zfs(1M) needs to handle unknown uid/gid in context of allow/unallow more gracefully

[ghost]

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.

[ghost]

Ping.

[ghost]

Ping again :)

[loli10K]

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.

This issue has been reported yesterday in the ZFS on Linux mailing list: it would be nice to get it fixed but maybe we should add a new test case to the "delegate" group?

[ghost]

Can we please get this integrated?

[ahrens]

@yuripv I'd like to have 2 reviewers. Should we integrate with Xin as the author and you and I as reviewers?

[ghost]

I made some changes to the original patch, but they seem to be cosmetic only, so yes, please list me as reviewer.

[ghost]

Ping.

[allanjude]

Reviewed By: Allan Jude allanjude@freebsd.org

[delphij]

Ping...

[prakashsurya]

illumos RTI is here

[ahrens]

This repo will be archived in the coming week, and therefore this PR is being closed. Alternate processes for contributing ZFS changes (including those in open PR's) include following the illumos procedures, or opening a PR against ZFSonLinux.

The reasoning behind this are outlined in an email to the developer@open-zfs.org mailing list, which is reproduced below:

The OpenZFS code repository on github (http://github.com/openzfs/openzfs) is a clone of the illumos repo, with basically identical code. The OpenZFS repo made it easier to contribute ZFS code to illumos, by leveraging the github pull request and code review processes, and by automatically building illumos and running the ZFS Test Suite.

Unfortunately, the automated systems have atrophied and we lack the effort and interest to maintain it. Meanwhile, the illumos code review and contribution process has been working well for a lot of ZFS changes (notably including ports from Linux).

Since the utility of this repo has decreased, and the volunteer workforce isn't available to maintain it, we will be archiving http://github.com/openzfs/openzfs in the coming week. Thank you to everyone who helped maintain this infrastructure, and to those who leveraged it to contribute over 500 commits to ZFS on illumos! Alternate processes for contributing ZFS changes (including those in open PR's) include following the illumos procedures, or opening a PR against ZFSonLinux.

The OpenZFS github organization (http://github.com/openzfs) will continue to exist. I will make an announcement about its future role at the OpenZFS Developer Summit on Monday.

Let me know if you have any questions,
--matt