![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Лонавала (тыкаble)
Jun. 29th, 2003 01:55 pm
Jun. 29th, 2003
Race Conditions
Jun. 29th, 2003 03:01 pmA ``race condition'' can be defined as ``Anomalous behavior due to unexpected critical dependence on the relative timing of events'' [FOLDOC]. Race conditions generally involve one or more processes accessing a shared resource (such a file or variable), where this multiple access has not been properly controlled.
In general, processes do not execute atomically; another process may interrupt it between essentially any two instructions. If a secure program's process is not prepared for these interruptions, another process may be able to interfere with the secure program's process. Any pair of operations in a secure program must still work correctly if arbitrary amounts of another process's code is executed between them.
Race condition problems can be notionally divided into two categories:
Interference caused by untrusted processes. Some security taxonomies call this problem a ``sequence'' or ``non-atomic'' condition. These are conditions caused by processes running other, different programs, which ``slip in'' other actions between steps of the secure program. These other programs might be invoked by an attacker specifically to cause the problem. This book will call these sequencing problems.
Interference caused by trusted processes (from the secure program's point of view). Some taxonomies call these deadlock, livelock, or locking failure conditions. These are conditions caused by processes running the ``same'' program. Since these different processes may have the ``same'' privileges, if not properly controlled they may be able to interfere with each other in a way other programs can't. Sometimes this kind of interference can be exploited. This book will call these locking problems.
In general, processes do not execute atomically; another process may interrupt it between essentially any two instructions. If a secure program's process is not prepared for these interruptions, another process may be able to interfere with the secure program's process. Any pair of operations in a secure program must still work correctly if arbitrary amounts of another process's code is executed between them.
Race condition problems can be notionally divided into two categories:
Interference caused by untrusted processes. Some security taxonomies call this problem a ``sequence'' or ``non-atomic'' condition. These are conditions caused by processes running other, different programs, which ``slip in'' other actions between steps of the secure program. These other programs might be invoked by an attacker specifically to cause the problem. This book will call these sequencing problems.
Interference caused by trusted processes (from the secure program's point of view). Some taxonomies call these deadlock, livelock, or locking failure conditions. These are conditions caused by processes running the ``same'' program. Since these different processes may have the ``same'' privileges, if not properly controlled they may be able to interfere with each other in a way other programs can't. Sometimes this kind of interference can be exploited. This book will call these locking problems.
как лепить формы
Jun. 29th, 2003 04:42 pmэтот пост ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
piggymouse напомнил мне мой freudian slip, когда я в 1997 году объяснял самому большому начальнику в Генезисе, почему после месяца работы нет видимого результата: "мы сейчас пишем инфрастуктуру... базовые классы там, то-сё... а лепить формы потом можно будет быстро-быстро... то есть не лепить, конечно, а очень аккуратно делать!"
piggymouse напомнил мне мой freudian slip, когда я в 1997 году объяснял самому большому начальнику в Генезисе, почему после месяца работы нет видимого результата: "мы сейчас пишем инфрастуктуру... базовые классы там, то-сё... а лепить формы потом можно будет быстро-быстро... то есть не лепить, конечно, а очень аккуратно делать!"