[External] : Re: RFR: 8319589: Attach from root to a user java process not supported in Mac [v2]

[Sergey Chernyshev]

Hi Larry,

Thanks for this note! If I understand correctly, "zz" corresponds to the 
first 10 bits of the encoded UUID attribute of LDAP user record, where 
all bits are set. Such records have UUIDs that start with FFFFEEEE-. 
They are special purpose user accounts, apart from `root`, that have 
their temp directories in zz bucket. If it's ignored, it will not be 
possible to attach/list JVMs running under special purpose accounts 
(which is theoretically possible).

Thanks,
Sergey

Am 18.06.25 um 23:51 schrieb Laurence Cable:
> I believe you can ignore bucket "zz"
>
> - Larry
>
> On 6/18/25 2:46 PM, Laurence Cable wrote:
>>
>>
>> On 6/18/25 12:44 PM, Sergey Chernyshev wrote:
>>> Hi Larry,
>>>
>>> Thank you for your comments! Yes, it's probably more like base 32 / 
>>> 5 bits per symbol. The function is actually __user_local_dirname, 
>>> it's exported by CoreServices (libsystem_coreservices.dylib). One 
>>> can dlopen() 
>>> /System/Library/Frameworks/CoreServices.framework/Versions/Current/CoreServices 
>>> and then lookup the __user_local_dirname (still works in 15.5 
>>> Sequoia). The problem is that the function is undocumented, it is 
>>> not exposed in any platform SDK headers and it is not reachable from 
>>> any documented api except for the confstr(), at least what i am 
>>> aware of. With the introduction of dyld shared cache in Big Sur the 
>>> approach became even less attractive. 
>>
>> Its probably not worth it, I followed a similar (fruitless) trail to 
>> the same conclusion a couple of years ago ... :(
>>
>>> I might need to look deeper into it.
>>>
>>> Thanks,
>>> Sergey
>>>
>>>
>>> Am 18.06.25 um 19:23 schrieb Laurence Cable:
>>>> I believe that somewhere in the bowels of MacOS libc there is a 
>>>> (hopefully public) function that will map a UID to the UUID used to 
>>>> construct
>>>> the per-user directory path from a base 36(?) encoded string 
>>>> thereof, the leading 2 characters of which form the "buckets" in 
>>>> /var/folders
>>>> and the remainder of the encoded string forms the per user 
>>>> directory with the appropriate bucket...
>>>>
>>>> if might make sense to perform a serious investigation to locate 
>>>> this function and then simply make a native call to map the target 
>>>> JVM euid
>>>> to the uuid and encode it, from which the actual /var/folders/... 
>>>> path can be constructed avoiding a costly traversal of the 
>>>> /var/folders
>>>> structure in the search for hsperfdata_user files?
>>>>
>>>> Rgds
>>>>
>>>> - Larry
>>>>
>>>> On 6/18/25 9:40 AM, Sergey Chernyshev wrote:
>>>>> On Tue, 17 Jun 2025 04:51:58 GMT, David Holmes 
>>>>> <dholmes at openjdk.org> wrote:
>>>>>
>>>>>>> Sergey Chernyshev has updated the pull request incrementally 
>>>>>>> with two additional commits since the last revision:
>>>>>>>
>>>>>>>   - Update 
>>>>>>> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java 
>>>>>>>
>>>>>>>         Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>>>>>>   - addressed review comments
>>>>>> src/hotspot/os/posix/perfMemory_posix.cpp line 133:
>>>>>>
>>>>>>> 131: //
>>>>>>> 132:
>>>>>>> 133: #ifdef __APPLE__
>>>>>> This is a bit too much non-posix code in the posix file IMO. I'd 
>>>>>> rather see a `MACOS_ONLY` call later on to something defined in 
>>>>>> `os_bsd.cpp` for macOS.
>>>>> Thanks @dholmes-ora , I moved the function to `os_bsd.cpp`
>>>>>
>>>>> -------------
>>>>>
>>>>> PR Review Comment: 
>>>>> https://git.openjdk.org/jdk/pull/25824#discussion_r2155061182 
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250624/cf2e65c1/attachment-0001.htm>