Hi, the manpage of getegid https://man7.org/linux/man-pages/man3/getegid.3p.html
says : " The getegid() function shall always be successful and no return value is reserved to indicate an error." So I am not sure what kind of additional check or error message you would expect ? > In this case, the exception message is clear that the gid is -1 so it should > help with debugging the issue. Yes , the message gives already some info, that's good (or better than nothing at least). Best regards, Matthias -----Original Message----- From: jdk-dev <jdk-dev-r...@openjdk.java.net> On Behalf Of Alan Bateman Sent: Freitag, 7. Januar 2022 12:48 To: stuart nelson <h...@stuartnelson.xyz>; jdk-...@openjdk.java.net Subject: Re: [libattach] misleading error message when checking gid fails On 07/01/2022 11:33, stuart nelson wrote: > Hey, > > First, apologies if this should be directed to a different mailing list, I > didn't find one that seemed correct in the mailing lists > (https://mail.openjdk.java.net/mailman/listinfo). > > I was building up a syscall filters list for a java process for seccomp, when > I encountered this error stack trace: > > (elided) > Caused by: java.io.IOException: well-known file > /proc/1974261/root/tmp/.java_pid1974261 is not secure: file's group should be > the current group (which is -1) but the group is 1000 > at > jdk.attach/sun.tools.attach.VirtualMachineImpl.checkPermissions(Native Method) > at > jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:112) > at > jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) > at > jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) > ... 6 more > > The error originates from this line: > https://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c#l167 > > The value for gid is found on this line: > https://hg.openjdk.java.net/jdk/jdk/file/ee1d592a9f53/src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c#l150 > > The reason getegid() returns -1 is because it wasn't in my allowed syscalls > list for seccomp, so EPERM (-1) was returned instead. > > My question is: -1 is an invalid gid. Should this be checked in the code, and > a more helpful error message returned? It could definitely save future > developers time. > serviceability-dev is the mailing lists for the Attach API. In this case, the exception message is clear that the gid is -1 so it should help with debugging the issue. -Alan
