RFR : 8211326 : add OS user related information to hs_err file

Thomas Stüfe thomas.stuefe at gmail.com
Mon Oct 8 09:43:57 UTC 2018 

Hi all,

I drafted a CSR:

https://bugs.openjdk.java.net/browse/JDK-8211846

Not sure what to do now, should I open a discussion thread on a
mailing list? Or just wait for the committee to decide? (I'm doing
this too rarely..)

Thanks, Thomas

On Thu, Oct 4, 2018 at 8:11 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> On Thu, Oct 4, 2018 at 11:18 AM David Holmes <david.holmes at oracle.com> wrote:
> >
> > Hi Thomas,
> >
> > On 4/10/2018 6:27 PM, Thomas Stüfe wrote:
> > > Hi David,
> > > On Thu, Oct 4, 2018 at 9:44 AM David Holmes <david.holmes at oracle.com> wrote:
> > >>
> > >> Hi Matthias,
> > >>
> > >> I'm hoping others will chime in here as I:
> > >>
> > >> a) don't know if this information is actually useful for an error log of
> > >> this kind;
> > >>
> > >> b) don't know if the information might be considered sensitive or not; and
> > >>
> > >
> > > I have no opinion on (a) and (b).
> >
> > That's a shame :)
> >
> > >> c) don't think it's worth the effort of adding a flag to control this.
> > >> Plus the flag is only useful for trying to reproduce an issue; if it's a
> > >> one-of failure then you've already missed out on the information in the
> > >> log file.
> > >
> > > How about a more generic switch to control verbosity of the error report?
> > >
> > > The way we and you use the error files seem to differ. You seem to
> > > prefer them short and snappy and bare any security relevant details
> > > (as far as that is even possible in an hs-err file). As was once
> > > mentioned in a similar discussion, "OpenJDK hs-err files get posted
> > > verbatim in forums and bug reports".
> > >
> > > We use the hs-err files differently. They are usually handed down to
> > > us by our customers thru secure channels, and for us size does not
> > > matter much, nor does security relevant information since we have
> > > contracts with our customers.
> >
> > To be honest I don't deal with hs-err files from other people very much
> > at all. But from what I have dealt with I haven't, to the best of my
> > recollection, encountered any crash investigation where all this extra
> > info would have shed any light. But most crashes I investigate are
> > developer related rather than end user.
>
> That may be the difference.
>
> We get crash reports from customers, often with little context, no
> repros, no cores, nothing. So we have to make do with what we have,
> which is the hs-err files. Therefore we make them as extensive as
> possible. Our support worked miracles with just these files. It is
> incredible what you can deduce from them.
>
> User information, e.g., can hint towards a mismanaged installation, if
> the server node does not run under the correct user. I also dimly
> remember it being useful in analyzing SIGBUS crashes for mapped files
> on Solaris.
>
> So, it turns out I have an opinion :) Well when I say no opinion I
> mean I can see arguments for both sides, and I feel uncomfortable
> pressing our way of working upon the OpenJDK code base.
>
> >
> > > That has been a point of contention over and over again in the past.
> > > So I wonder whether one, or possibly two, general switches could keep
> > > both sides happy. Something like -XX:+ExtendedErrorReports" and
> > > possibly "-XX:+ErrorReportsIncludeSensitiveData".
> > >
> > > Those switches could be, by default, false in the OpenJDK.
> > >
> > > Any additions we add to error reporting where we cannot find an
> > > agreement we could make conditional on one or the other switch.
> > >
> > > What do you think?
> >
> > Seems reasonable to propose. Any new flag will require a CSR request.
> >
>
> Okay, thanks!
>
> I will file a CSR next week when I am back at the office.
>
> ..Thomas
>
> > David
> >
> > > ..Thomas
> > >
> > >>
> > >> Cheers,
> > >> David
> > >>
> > >>
> > >> On 4/10/2018 5:31 PM, Baesken, Matthias wrote:
> > >>> Hello,  my proposal  would be to  only print
> > >>>
> > >>> uid : 1679 (testuser-name)
> > >>>
> > >>> by default  and guard  the rest of the info  by some XX-flag, any good proposals  for the flag-name are appreciated;
> > >>>    for example :
> > >>>
> > >>> if  (ExtendHsErrorFileByUserRelatedInformation)  {
> > >>>
> > >>>     // print those too :
> > >>>
> > >>>>>> euid : 1679 (testuser-name)
> > >>>>>> gid : 25 (testgroup)
> > >>>>>> egid : 25 (testgroup)
> > >>>>>>
> > >>>>>> umask: 0022 (removing ----w--w-)
> > >>>
> > >>> }
> > >>>
> > >>>
> > >>> Best regards, Matthias
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Baesken, Matthias
> > >>>> Sent: Dienstag, 2. Oktober 2018 12:38
> > >>>> To: 'David Holmes' <david.holmes at oracle.com>; 'hotspot-
> > >>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> > >>>> Subject: RE: RFR : 8211326 : add OS user related information to hs_err file
> > >>>>
> > >>>> Hi David,  I think the added info   could be seen more or less in line   with
> > >>>> what currently is reported in hs_err file .
> > >>>> For instance you usually see  user-names and lots of paths from the system
> > >>>> in the hs_err file .
> > >>>>
> > >>>> In case the umask and gid  is  seen as more sensitive than that,  one could
> > >>>> make  the output switchable with  an XX-flag ;
> > >>>>    this  would have the  benefit of making the added output more clear to the
> > >>>> user/admin .
> > >>>>
> > >>>> Best regards, Matthias
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: David Holmes <david.holmes at oracle.com>
> > >>>>> Sent: Dienstag, 2. Oktober 2018 09:49
> > >>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> > >>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> > >>>>> Subject: Re: RFR : 8211326 : add OS user related information to hs_err file
> > >>>>>
> > >>>>> Hi Matthias,
> > >>>>>
> > >>>>> On 2/10/2018 5:30 PM, Baesken, Matthias wrote:
> > >>>>>> Hello , please review this small enhancement to the hs_err file .
> > >>>>>>
> > >>>>>> Currently the hs_err file contains only limited OS user related
> > >>>> information.
> > >>>>>> Just the user name is printed via output of environment variables (at
> > >>>> least
> > >>>>> on Windows with USERNAME - output).
> > >>>>>> The enhanced output on UNIX would contain more information including
> > >>>>> uid, gid and umask  :
> > >>>>>>
> > >>>>>> uid : 1679 (testuser)
> > >>>>>> euid : 1679 (testuser)
> > >>>>>> gid : 25 (testgroup)
> > >>>>>> egid : 25 (testgroup)
> > >>>>>>
> > >>>>>> umask: 0022 (removing ----w--w-)
> > >>>>>
> > >>>>> Could any of this be considered sensitive information by an end-user?
> > >>>>>
> > >>>>> Thanks,
> > >>>>> David
> > >>>>>
> > >>>>>>
> > >>>>>> (  Some of the info above could be found currently  in error logging
> > >>>> output
> > >>>>> e.g.
> > >>>>>>                attachListener_linux.cpp   line 362
> > >>>>>>                log_debug(attach)("euid/egid check failed (%d/%d vs %d/%d)",
> > >>>>>> (and the user name on Windows(-only) is in the env variables section).
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> bug/webrev :
> > >>>>>> ----------------------
> > >>>>>>
> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8211326
> > >>>>>>
> > >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8211326.0/
> > >>>>>>
> > >>>>>>
> > >>>>>> Thanks, Matthias
> > >>>>>>

More information about the hotspot-dev mailing list