[libattach] misleading error message when checking gid fails

[Serguei Spitsyn]

Hi,

Just some addition to the below comment.
The man page also has this:

RATIONALE         top

       In a conforming environment, getegid() will always succeed. It is
       possible for implementations to provide an extension where a
       process in a non-conforming environment will not be associated
       with a user or group ID. It is recommended that such
       implementations return (gid_t)-1 and set errno to indicate such
       an environment; doing so does not violate this standard, since
       such an environment is already an extension.

I'm not sure what kind of a better message users would like to have in case the (gid_t)-1 is returned.
Current message is pretty good providing this returned value which helps to identify problem.

Thanks,
Serguei

On 1/7/22, 4:05 AM, "serviceability-dev on behalf of Baesken, Matthias" <serviceability-dev-retn at openjdk.java.net on behalf of matthias.baesken at sap.com> wrote:

    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-retn at openjdk.java.net> On Behalf Of Alan Bateman
    Sent: Freitag, 7. Januar 2022 12:48
    To: stuart nelson <hi at stuartnelson.xyz>; jdk-dev at 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