Bug ID: JDK-8241568 (fs) UserPrincipalLookupService.lookupXXX failure with IOE "Operation not permitted"

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 11	JDK 13	JDK 14	JDK 15
11.0.10-oracleFixed	13.0.4Fixed	14.0.2Fixed	15 b18Fixed

java/nio/file/attribute/PosixFileAttributeView/Basic.java has started to fail recently on two Ubuntu 18.04 aarch64 systems at SAP.

An example failure is:

-- Lookup UserPrincipal Tests --
lookup: jvmtests
lookup group: kmem
lookup: scumbag99
----------System.err:(17/1126)----------
java.io.IOException: scumbag99: Operation not permitted
	at java.base/sun.nio.fs.UnixUserPrincipals.lookupName(UnixUserPrincipals.java:148)
	at java.base/sun.nio.fs.UnixUserPrincipals.lookupUser(UnixUserPrincipals.java:170)
	at java.base/sun.nio.fs.UnixFileSystem$LookupService$1.lookupPrincipalByName(UnixFileSystem.java:328)
	at Basic.lookupPrincipalTests(Basic.java:305)
	at Basic.main(Basic.java:390)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:834)

JavaTest Message: Test threw exception: java.io.IOException: scumbag99: Operation not permitted

It appears that that getpwnam_r and getgrnam_r are failing with the error EPERM when these libc functions are called to lookup user or group names that do not exist.

As per man page of getpwnam_r, EPERM is a well defined error code that should indicate that "The given name or uid was not found."

https://linux.die.net/man/3/getpwnam_r

Errors
0 or ENOENT or ESRCH or EBADF or EPERM or ...

The given name or uid was not found.

I suggest to add EBADF and EPERM to the checked return codes in UnixNativeDispatcher.c

Fix request (13u) Requesting backport to 13u for parity with 11u, applies cleanly.
08-06-2020
Fix request (14u, 11u): Requesting backport of this fix to 11 and 14 because the issue can be reproduced in these releases as well when the problematic system configuration is encountered. The test failure is observed then, too. The patch applies cleanly to both.
31-03-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/ee44884f3ab8 User: clanger Date: 2020-03-31 07:11:44 +0000
31-03-2020
Okay, just surprised that these errors are only seen now.
26-03-2020
[~alanb] The systems use sssd with the services "nss,pam,sudo,ssh" - Domain is our global Active Directory. It is a Ubuntu 18.04. We have no Ubuntu 16.04 for aarch. And we have no other Ubuntu systems using sssd for authentication as far as I know.
25-03-2020
[~azeller] Can you shed some light on the configuration of the aarch machines, e.g. do we use LDAP or NIS there? Also, do we have an Ubuntu 16.0.4 system with the same configuration where we can test this and see whether it would fail there as well? [~alanb] I'll try this patch for UnixNativeDispatcher.c tonight: diff --git a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c --- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c +++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c @@ -1244,7 +1244,7 @@ if (res != 0 \|\| p == NULL \|\| p->pw_name == NULL \|\| (p->pw_name) == '\0') { / not found or error / - if (errno != 0 && errno != ENOENT && errno != ESRCH) + if (errno != 0 && errno != ENOENT && errno != ESRCH && errno != EBADF && errno != EPERM) throwUnixException(env, errno); } else { uid = p->pw_uid; @@ -1286,7 +1286,7 @@ retry = 0; if (res != 0 \|\| g == NULL \|\| g->gr_name == NULL \|\| (g->gr_name) == '\0') { /* not found or error / - if (errno != 0 && errno != ENOENT && errno != ESRCH) { + if (errno != 0 && errno != ENOENT && errno != ESRCH && errno != EBADF && errno != EPERM) { if (errno == ERANGE) { / insufficient buffer size so need larger buffer */ buflen += ENT_BUF_SIZE; Would you think that this could be a possible solution? Or is it a bad idea for some reason to handle EBADF and EPERM as tolerated outcome?
25-03-2020
[~clanger] Can you add the configuration to the bug report? Also would be be useful to track down what has changed in the Linux libraries.
25-03-2020