Merge ~ahasenack/ubuntu/+source/libnfsidmap:bionic-uid-map-krb5-1819197 into ubuntu/+source/libnfsidmap:ubuntu/devel
Status: | Superseded |
---|---|
Proposed branch: | ~ahasenack/ubuntu/+source/libnfsidmap:bionic-uid-map-krb5-1819197 |
Merge into: | ubuntu/+source/libnfsidmap:ubuntu/devel |
Diff against target: |
59 lines (+38/-0) 3 files modified
debian/changelog (+7/-0) 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+364915@code.launchpad.net |
This proposal has been superseded by a proposal from 2019-03-22.
Description of the change
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://
I did a codesearch in debian (https:/ /codesearch. debian. net/search? q=nfs4_ gss_princ_ to_ids) for nfs4_gss_ princ_to_ ids, and the only non-libnfsidmap package that calls it is nfs-utils. Doesn't tell me yet if that function always uses a well formatted principal name.