Merge ~ahasenack/ubuntu/+source/libnfsidmap:disco-uid-map-krb5-1819197 into ubuntu/+source/libnfsidmap:ubuntu/devel
Status: | Merged |
---|---|
Approved by: | Christian Ehrhardt |
Approved revision: | 32b7e120e9265f68e992a9df83130f50b41bbcbf |
Merged at revision: | 32b7e120e9265f68e992a9df83130f50b41bbcbf |
Proposed branch: | ~ahasenack/ubuntu/+source/libnfsidmap:disco-uid-map-krb5-1819197 |
Merge into: | ubuntu/+source/libnfsidmap:ubuntu/devel |
Diff against target: |
73 lines (+40/-1) 4 files modified
debian/changelog (+7/-0) debian/control (+2/-1) debian/patches/03-uid-map-krb5.patch (+30/-0) debian/patches/series (+1/-0) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Christian Ehrhardt (community) | Approve | ||
Canonical Server Core Reviewers | Pending | ||
Review via email: mp+364954@code.launchpad.net |
Description of the change
[copied from the bionic MP]
This fixes a very old bug, reported multiple times in both debian[1] and ubuntu[2].
Testing it might be a bit complicated, I just so happened to have a kerberos + nfsv4 setup at home already, I'll think of an easy way to set something up when the SRU time comes.
There have been two versions of the fix floating around across all these bugs. Compounded with that, there doesn't seem to be an official upstream anymore.
Patch 1[3], which is what I used here, fixes nss.c:strip_
The second patch[5] has that hunk, plus another one to fix nss.c:nss_
- princ_realm = strstr(princ, "@");
+ princ_realm = strrchr(princ, '@');
It's not clear to me when that function is used. I would have to understand that to check what kind of (incorrect) values could be given to the "princ" variable. If it's really just given a principal (which is of the form user@REALM), then both strstr() and strrchr() would yield the same result. One could argue that it wouldn't hurt to always return the last "@" occurrance (and not the first), though.
The most up-do-date release I found for libnfsidmap2 is 0.27[6], and that seems to be a self-appointed version done by Redhat. Citi, which is the site mentioned in d/control, still has only 0.25[7]
0.27 does NOT contain the second fix, just the first.
I emailed Steve D. (from that fedorapeople site 0.27 release) asking who is upstream now, he said he doesn't think there is one.
I would need a lot more investigation to understand when the second patch is needed. So given:
- 0.27 does not contain the second fix
- I found no other reference to the second fix "in the wild", just in these bug reports, and no follow-up confirmation about what is fixed (I specifically asked in https:/
- the first patch fixes the reported problem scenario
- beta freeze is looming
I'm inclined to upload just with the first patch hunk, and later update it if needed.
1. http://
2. https:/
3. https:/
4. https:/
5. https:/
6. https:/
7. http://
Thanks for preparing a Disco MP - this LGTM now.
Content is the same as already reviewed - Version number is ok for this upload.