RFR 8138579: Custom launcher fails to start because of permission problem
Jaroslav Bachorik
jaroslav.bachorik at oracle.com
Wed Oct 7 21:03:11 UTC 2015
On 7.10.2015 22:44, ecki at zusammenkunft.net wrote:
> Hm, how can a normal user "give away" the ownership of a file? Only when the test is run as root the owner can be different, but in that case root would be able to set the x bit anyway. So i am not sure the explanation is correct? (Cant read the bug)
This is happening on the testing farm. It's pretty unlikely to hit it on a single machine. But on the testing farm the JDK sources can be checked out by one user into an NFS share and then the files can be used in tests, possibly by a different user. Since the test copies over the file originally checked out by a different user and preserves its attributes it is not possible for the current user top change the executable flag afterwards.
Example:
1. check out the source such as CustomLauncher test is located at /net/shared_location/blah/CustomLauncher by userA
2. copy the launcher file, preserving the attributes by userB while preserving attributes
/net/shared_location/blah/CustomLauncherTest/amd64/launcher [owner: userA, group: groupA] -> /net/shared_location/blah/CustomLauncher/launcher [owner: userA, group: groupB]
3. try to set the executable flag by userB - it fails since userB is not the owner of /net/shared_location/blah/CustomLauncher/launcher
---
By not preserving the attributes in step 2 this problem is solved and test is passing on all platforms.
-JB-
>
> Gruss
> Bernd
>
More information about the serviceability-dev
mailing list