RFR : 8211326 : add OS user related information to hs_err file
Thomas Stüfe
thomas.stuefe at gmail.com
Mon Oct 8 10:21:24 UTC 2018
On Mon, Oct 8, 2018 at 11:50 AM David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Thomas,
>
> On 8/10/2018 7:43 PM, Thomas Stüfe wrote:
> > 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..)
>
> I filled in some of the additional info needed. The text needs to be
> completed and the CSR needs to have at least one reviewer added to it.
> Then it can be marked "final" and ready for the committee to evaluate.
>
Thanks! I filled out what was missing and will wait for reviewers.
Thanks, Thomas
> David
>
> > 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