Thanks!
On 03/12/2014 19:50, Staffan Larsen wrote:
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
