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

David Holmes david.holmes at oracle.com
Mon Oct 8 09:50:22 UTC 2018 

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.

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