Java
Comments 30
+40
Ты только что разрушил мой маленький безопасный мир Явы!
+5
А может быть наоборот, он показал где стоит искать магию в чужом приложении, когда наблюдаемые баги начинают выходить за грани разумного и ты уже не понимаешь, где еще смотреть косяки?
UFO landed and left these words here
0
Ага, интересная штука. Хотя применять не доводилось. А тебе? И внутри JDK, похоже, нигде не используется.
UFO landed and left these words here
UFO landed and left these words here
-1
«Мы с Doug Lee...» звучит очень круто. Что, прямо на самом деле?
UFO landed and left these words here
-2
Я чего-то не понял. Почему команду интересует безопасность межпоточной работы MappedByteBuffer, при том, что у них есть класс, наследование от которого даёт доступ ко всем приватным членам?
+2
MappedByteBuffer — часть public API Java. Его использование документировано и поощряется. MagicAccessor таковым не является.
0
Да, но если им может воспользоваться каждый, кто о нём знает, не является ли это проблемой безопасности?
+1
Гм. Нет, конечно. Причем тут безопасность? Каждый знает, что Яву можно пропатчить или посмотреть дебаггером. Класс отмечен как внутренний. Хотите — пользуйтесь, только не говорите потом, что команда Oracle виновата в том, что софт на вашем кластере за миллион долларов глюканул из-за неумелого использования вами недокументированных и даже явно отмеченных как внутренние классов Java.

А вот если MappedByteBuffer начнет работать некорректно при документированном, легитимном использовании, команда Oracle будет в этом виновата. Я уж не знаю про материальную ответственность, но с моральной точки зрения, в глазах сообщества — несомненно.
0
Я вообще вот к чему. Положим есть система запуска заданий от различных пользователей, полагающаяся на систему безопасности Java. Система запуска читает из файла задания путь к jar файлу, создаёт новый поток, переходит в нём в контекст безопасности пользователя Alice, автора этого задания. Затем выполняет аналогичные действия с заданием Bob'а. Далее задание Alice открывает MappedByteBuffer.

Теперь внимание: в комментарии к багу написано, что размапить этот буфер вручную нельзя, т.к. тогда если сразу после этого Bob замапит другой буфер на освободившуюся память, то Alice, из-за того, что разработчки Java хотят быстрый доступ к этим буферам и потому не хотят при каждом обращении проверять, был ли он освобождён или нет, сможет через ссылку на класс размапленного буфера получить доступ к файлам Bob.

Но! Если Alice знает про MagicAccessor и наследует он него свой класс, то она может напрямую получить доступ к приватным данным Боба, содержащихся в приватных полях класса, ссылку на который он ей как-нибудь передал. Или, хуже того, через приватные поля классов самой JVM или какой-нибудь из совместно используемых библиотек.
+2
Если Alice знает про MagicAccessor и наследует он него свой класс...

Но ведь с таким же успехом Alice может использовать JNI в своем классе / jar'е и делать вообще все, что заблагорассудится. Ну или просто приватные поля можно через Reflection читать. Но при желании подобные вещи можно отловить верификатором. А вот некорректное использование функционала «размапливания» буфера будет не отловить. Поскольку сама операция будет легитимной. Опасны последствия.
+5
В Java есть понятия политики безопасности и пермиссий. Когда вы запускаете java локально, SecurityManager выключен, поэтому вам и позволены все эти хаки. Теперь попробуйте запустить java с параметром -Djava.security.manager и тут же получите java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.misc). Java — безопасная платформа (для аплетов, например, SecurityManager всегда включен), но она не ограничивает возможности тех, кто знает, что делает.
0
Спасибо, уволок в избранное. Может пригодиться при отладке чужого кода.
0
Не могу понять чем использование sun.misc.Cleaner лучше «Finalizer Guardian idiom»?
+2
Отвечу комментариями к исходникам:
Cleaners are a lightweight and more robust alternative to finalization. They are lightweight because they are not created by the VM and thus do not require a JNI upcall to be created, and because their cleanup code is invoked directly by the reference-handler thread rather than by the finalizer thread. They are more robust because they use phantom references, the weakest type of reference object, thereby avoiding the nasty ordering problems inherent to finalization.

Cleaners may also be invoked directly; they are thread safe and ensure that they run their thunks at most once.
0
Очень интересно и познавательно! Огромное спасибо!
0
О, неужто теперь в университетах появится (блекджек и шлюхи) порно?

А если серьезно, то домены можно было бы использовать и по назначению, т.е. и сексуального образования. А то абстрактным предметам, которые, возможно, никогда и не пригодятся, в университетах обучают, а тому, с чем каждый имеет дело каждый день — нет. В результате имеем лицемерие: с одной стороны тема заглатывается, с другой — пороки легкодоступны, и не только касаемо секса.

А еще серьезней — получается, каждый должен купить домен в зоне .ru, .com и .xxx, «чтобы какой-нибудь негодяй не опозорил мое имя и не обманул мою потенциальную аудиторию!»?
+1
Вы вынесли мне моск, абсолютно! Перечитал два раза, пытасяь понять, как ваш комментарий относится к топику)
0
А сюда вот что скажу — спасибо, интересно, только жаль, что эти методы не надежны (могут не быть или исчезнуть) и не становятся частью public API, а было бы весьма полезно…
+1
Один я не могу найти в JDK 6 класс sun.misc.MagicAccessorImpl?
Возможно вы имели ввиду sun.reflect.MagicAccessorImpl?
0
Конечно, sun.reflect. В примере указал правильно, а здесь на автомате не то написал. Спасибо, поправил.
Only those users with full accounts are able to leave comments.  , please.