I agree. Go ahead with this and hopefully we can revisit it later.
Thanks,
/Staffan
> On 3 dec 2014, at 17:17, KEVIN WALLS <kevin.wa...@oracle.com> wrote:
>
> Thanks Staffan -
>
> Yes, I've updated it to be simply canAttachOSX(). Seems likely we should go
> ahead with that and possibly revisit the OSX conditions, good to have the
> method there so we can make it more complete and complex later when/if
> required. Right now, I think this is suitable for our automated tests, it
> could be that we are stopping people (you? 8-) ) running this automated test
> as a non-root user, such tests will not execute, but shouldn't fail...
>
> Thanks
> Kevin
>
>
> On 03/12/2014 12:53, Staffan Larsen wrote:
>> 178 public static boolean canPtraceAttachOSX() throws Exception {
>> 179 return userName.equals("root");
>> 180 }
>>
>> Ptrace isn’t the API that is doing the most vigorous access checks on OS X.
>> Instead the system call task_for_pid() is what causes most of the access
>> denied problems. So perhaps just skipping the “Ptrace” part of the method
>> name above is good.
>>
>> Then, on OS X again, the root user will indeed av access to other processes,
>> but it’s not the only way. A regular user can also get access if a couple of
>> prerequisites are met:
>> 1) The attaching program is compiled with SecTaskAccess=allowed in
>> Info.plist. We do this for jstack, jinfo and jmap.
>> 2) The attaching program is signed.
>> 3) The user has given permission for taking control of another process via a
>> dialog box that OS X displays.
>> (I think these are all…)
>>
>> Regarding signing above: Oracle signs binaries that we ship with an official
>> certificate, but development binaries are also signed if a certificate
>> called openjdk_codesign is found on the machine where the product is built.
>> Usually one creates a self-signed such certificate if one wants to test the
>> attaching functionality.
>>
>> All this to say that if we only check for root, then it will not be possible
>> to run the tests as a regular user even if you have done 1-3 above. That
>> would be a shame, but perhaps cannot be avoided given the complexity
>> involved.
>>
>> /Staffan
>>
>>
>>> On 26 nov 2014, at 14:53, KEVIN WALLS <kevin.wa...@oracle.com> wrote:
>>>
>>>
>>> ...and an update to the webrev in the same place that also checks the
>>> SELinux deny_ptrace flag, another reason you can get a permission denied
>>> error and fail the test.
>>>
>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/
>>>
>>> Thanks
>>> Kevin
>>>
>>>
>>> On 20/11/2014 18:38, KEVIN WALLS wrote:
>>>> Hi,
>>>>
>>>> I'm resurrecting this thread to revisit this testcase, the one that fails
>>>> if not in an environment where an SA attach is permitted (which is linux
>>>> systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac systems as a
>>>> non-root user).
>>>>
>>>> There are times when we want to check if an SA attach is likely to work,
>>>> so in the following webrev I've put that in the testlibrary.
>>>>
>>>> In doing this I now realise that heap dumping with jmap/sa is broken, as
>>>> reported in: https://bugs.openjdk.java.net/browse/JDK-8044416
>>>>
>>>> I won't remove the @ignore in this change, but it would make sense to me
>>>> to do the fix below, including backporting to places where jmap -F still
>>>> works.
>>>>
>>>> webrev
>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/
>>>>
>>>> bug
>>>> https://bugs.openjdk.java.net/browse/JDK-8039995
>>>>
>>>> Thanks
>>>> Kevin
>>>>
>>>>
>>>>
>>>>
>>>> On 24/05/2014 19:25, Kevin Walls wrote:
>>>>> Thanks Peter, and thanks Dmitry -
>>>>>
>>>>> So another thread on this has started about why such a test runs in an
>>>>> environment that can't expected to attach to its own processes anyway:
>>>>> seems that some test systems permit that, and some run as a user that
>>>>> can't necessarily expect to have that ability.
>>>>>
>>>>> (Dmitry I'm not sure about exiting with that error value? If that's
>>>>> something people are meant to know about I have missed it. But the test
>>>>> would fail if jmap didn't create the heap dump file, i.e. if it fails but
>>>>> doesn't exit with the right code.)
>>>>>
>>>>> For the moment I'll wait on that other information for whether this needs
>>>>> to be fixed in the test...
>>>>>
>>>>> Thanks!
>>>>> Kevin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 23/05/14 12:00, Peter Allwin wrote:
>>>>>> Looks good to me!
>>>>>>
>>>>>>
>>>>>> Thanks for looking at this Kevin,
>>>>>> /peter
>>>>>>
>>>>>> On 20 May 2014, at 13:14, Kevin Walls <kevin.wa...@oracle.com> wrote:
>>>>>>
>>>>>>> Hi - any comments? 8-)
>>>>>>>
>>>>>>> On 12/05/14 16:02, Kevin Walls wrote
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'd like to get a review of this test change. It assumed that jmap
>>>>>>>> would have permission to run on a process that the test itself
>>>>>>>> created, but this is not necessarily the case.
>>>>>>>>
>>>>>>>> Here I'm considering it OK to skip (pass) the test where jmap fails to
>>>>>>>> attach. The test itself was not platform-specific and as long as we
>>>>>>>> have other platforms where jmap step will work, we are testing for
>>>>>>>> this problem.
>>>>>>>>
>>>>>>>> bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039995
>>>>>>>>
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Kevin
>
