Уязвимость в парадигме функционального программирования?
Задания PowerShell (типа PSJob) выполняются в отдельном процессе, поэтому они не имеют никакого доступа к среде вызывающей программы, даже к переменным в глобальной области.
Чтобы получить информацию в задании, вы должны определить блок param() в блоке сценария задания, а затем использовать параметр -ArgumentList в Start-Job для отправки значений. Обратите внимание, что это будет однократная передача значений .
Чтобы вернуть данные из задания, вы просто отправляете их по конвейеру, как обычно, и для доступа к данным вам нужно будет использовать Get-Job, чтобы определить, есть ли у задания «дополнительные данные», и если это так , вы используете Receive-Job для извлечения этих данных.
К сожалению, все это означает, что вам все еще нужен ваш основной поток для управления фоновым заданием, чтобы победить цель.
Вы можете вместо заглянуть в [117] и связать его с каким-то объектом .Net, который может вызывать события. Похоже, что они выполняются в процессе, но более того, они могут запускаться на основе событий, которые могут вас заинтересовать, без управления циклом.
Итак, в самом простом и, возможно, просто для ознакомления вы можете взглянуть на пример таймера, где объект таймера запускает событие с интервалом:
$timer = new-object timers.timer
$action = {write-host "Timer Elapse Event: $(get-date -Format ‘HH:mm:ss’)"}
$timer.Interval = 3000 #3 seconds
Register-ObjectEvent -InputObject $timer -EventName elapsed –SourceIdentifier thetimer -Action $action
$timer.start()
#to stop run
$timer.stop()
#cleanup
Unregister-Event thetimer
Но примеры на странице Microsoft даже включают мониторинг события создания процесса из WMI, так что и / или и событие выхода из процесса (?), Возможно, стоит посмотреть.
4 ответа
Если программист не ожидает, что [некоторый вход] мог заставить [программа] использовать больше, чем имеющиеся ресурсы, это - уязвимость в форме возможного DoS. Это - слабость всех полных по Тьюрингу языков, которые я видел, но лень Haskell мешает рассуждать о том, что включает вычисление.
Как (скорее изобретенный) пример,
import Control.Monad (when)
import System (getArgs)
main = do
files <- getArgs
contents <- mapM readFile files
flip mapM_ (zip files contents) $ \(file, content) ->
when (null content) $ putStrLn $ file ++ " is empty"
Наивный программист может думать, "Haskell ленив, таким образом, это не откроет и считает файлы, пока этому не будет нужно к", и "Haskell собран "мусор", поэтому после того как это сделано с файлом, это может закрыть дескриптор файла". К сожалению, эта программа на самом деле просто откроет много файлов, внезапно (определенных для реализации), и только пустые файлы получат свои закрытые дескрипторы файлов (побочный эффект правил живости реализации):
$ ghc --make -O2 Test
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ strace -etrace=open,close ./Test dir/* /dev/null
...
open("dir/1", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 3
open("dir/2", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 4
open("dir/3", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 5
open("dir/4", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 6
open("dir/5", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 7
...
open("/dev/null", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 255
close(255)
/dev/null is empty
$
Вы не могли бы ожидать-EMFILE "Слишком много открытых файлов" ошибка когда-либо произойти.
Как я сказал, это - изобретенный пример и может произойти на других языках также, но просто легче пропустить определенное использование ресурсов в Haskell.
Функциональные языки имеют недооцениваемую "безопасность через мрак", способствуют из-за их моделей выполнения. Если Вы смотрите на использование безопасности в программах C, они используют в своих интересах слабую систему типов, управление указателем и отсутствие проверки границ, но что еще более важно они используют в своих интересах хорошо понятую, простую модель выполнения. Например, можно надежно разбить стек в C, потому что относительно легко знать, где стек, только путем взятия адреса локальных переменных. Много другого использования полагаются на подобное понимание низкого уровня модели выполнения.
Напротив, совсем не настолько очевидно, как функциональный код будет скомпилирован вниз в двоичный файл, таким образом, будет совсем не настолько легко разработать рецепт для того, чтобы выполнить введенный код или получить доступ к привилегированным данным. Как ни странно, мрак моделей выполнения обычно считают слабостью функциональных языков, так как у программистов не всегда есть хорошая интуиция того, как их код будет работать.
Я так не думаю.
Поскольку я вижу его вместо парадигмы программирования, уязвимости как переполнение буфера больше имеет отношение к архитектуре/виртуальной машине компилятора/интерпретатора.
Для, например, при использовании функционального программирования в среде.NET (C#, VB и т.д.), пока Вы имеете дело с управляемыми объектами, переполнение буфера будет заботиться о.
Может быть возможно более легко вызвать неограниченную рекурсию (и получающееся использование памяти) в функциональной реализации, чем в соответствующей обязательной реализации. В то время как обязательная программа могла бы просто войти в бесконечный цикл при обработке уродливых входных данных, функциональная программа может вместо этого проглотить всю память, это может при выполнении той же обработки. Обычно это была бы ответственность VM, в котором программа работает для ограничения объема памяти, который может использовать конкретный процесс. (Даже для собственных процессов Unix, ulimit может обеспечить эту защиту.)