Опасный код на C

Перевод цикла статей David Chisnall «Writing Insecure C, Part 1», «Writing Insecure C, Part 2», «Writing Insecure C, Part 3».

Использование языка программирования C часто приводит к написанию очень опасного кода. Но это не совсем справедливое обвинение; такие проекты, как OpenBSD показывают, что возможно писать безопасный код на C. Проблема C та же, что и в ассемблере — язык открывает вам все возможности архитектуры, но и кое-что ещё. Он дает все возможности для написания безопасного кода, но не делает эти вещи сам.

В этой статье рассмотрены стандартные примеры ошибок в коде C и то, как их и избежать.

Проверка ошибок

Множество современных языков включают в себя некоторый механизм по обработке исключений. Вообще, исключения — это плохая идея. Они усложняют управление ходом программы и у них есть большинство недостатков, от которых страдали программы с GOTO перед рассветом структурного программирования. Тем не менее, у исключений есть одно важное преимущество: вы не можете их игнорировать.

В частности, код на Java часто засорен блоками try…catch, которые ничего не делают, кроме отбрасывания ошибок, но даже в этом случае механизм исключений преследует цель: это заставляет программиста помнить о том, что он небезопасно обрабатывает условия ошибок.

В C большинство функций возвращают неправильное значение, когда произошла какая-либо ошибка. Обычно это делается двумя способами. Множество функций возвращают код ошибки ноль в случае успеха. Функции, возвращающие указатели, возвращают правильное значение в случае успеха или ноль в противном случае. Эта ситуация может немного смущать, так как ноль означает и успешное выполнение одних функций, и ошибку в других.

Можно возвращать нулевой указатель. Это вы не сможете легко проигнорировать, так как получите ошибку сегментации, как только попытаетесь разыменовать его. Этот подход действительно опасен только в тех функциях, которые почти никогда не завершаются с ошибкой; в других ошибка может быть обнаружена во время тестирования и исправлена.

Стандартный пример функции, которая почти никогда не завершается с ошибкой — malloc(), наряду со связанными с ней функциями, вроде calloc(). В спецификации C указано, что malloc должна вернуть NULL в случае, если памяти недостаточно, чтобы удовлетворить запрос. Linux не полностью следует этому правилу: он возвращает NULL, если в системе нет достаточного виртуального пространства адресов, чтобы выполнить выделение памяти, но в случае недостатка памяти, Linux по-прежнему выделяет пространство адресов, а затем возвращает ошибку, если вы пытаетесь использовать эту память. Как бы то ни было, исходя из того, что у вас есть подходящая реализация C, необходимо проверять значения, которые возвращает malloc.

В большинстве случаев, вы не сможете сделать ничего разумного, если malloc завершится с ошибкой. Даже код, восстанавливающий ошибку, обычно нуждается в выделении памяти. Вы можете попробовать выделять эту память, когда программа запускается (не забудьте проверить, что вы можете получать к ней доступ). В качестве альтернативы, вы можете использовать что-нибудь вроде этого макроса:

#define MALLOC(x,y) do { y = malloc(x); if (!y) abort(1); } while(0)

Он будет тестировать каждое выделение памяти, и прерывать программу в случае ошибки. Вы можете заменить вызов abort на ваш код, обрабатывающий ошибку, но будьте осторожны. Одна из недавних уязвимостей в OpenSSH была вызвана вызовом кода, восстанавливающего ошибку в ситуации, когда программа была в неопределенном состоянии. Зачастую, прерывание выполнения безопаснее.

Точно также важна проверка возвращаемых значений других функций.

Начальные значения

Если вы объявляете глобальную переменную в C, она безоговорочно инициализируется нулем. Этот способ очень удобный, и был бы ещё более удобным, если бы вы могли верить, что автор вашего компилятора прочитал эту часть спецификации. Как бы то ни было, если вы получаете память из любого другого источника, это правило не работает.

При объявлении локальной переменной, компилятор выполняет это как простой инкремент верхнего регистра стека. Начальное значение переменной будет таким, каким последняя функция его установила, использовав эту часть памяти стека.

Здесь существуют две потенциальные проблемы. Первая в том, что невозможно предсказать поведение неинициализированной переменной. Вторая в том, что этого может и не быть. В общем, использование значения перед инициализацией приведет к неопределенному состоянию вашей программы. В худшем случае, это может привести к утечке информации. Например, если вы пишете некоторый код, который использует неинициализированную переменную после вызова функции шифрования, ваше «случайное» значение неопределенной переменной может содержать некоторую часть ключа шифрования. Если ваш код запускает скрипты, которые могут читать информацию из стека, это может быть серьезной уязвимостью.

Ещё несколько проблем могут случиться с неинициализированными переменными. Одна из самых ужасных, что я видел, это когда вы начинаете с кода, который выглядит как-то так:

int a = 42;

А затем вы решаете, что вам необходимо условие для инициализации, поэтому вы копируете и вставляете его в выражение if:

if ({некоторое условие})
 
{
 
   int a = 42;
 
}

Ой, вы же забыли объявить переменную за пределами блока if, поэтому вы делаете это позже, и даете ей значение по умолчанию:

int a = 0;
 
if ({некоторое условие})
 
{
 
   int a = 42;
 
}

Теперь у вас есть код, который компилируется и запускается. Большинство времени (когда не встречается условие), он будет работать. Но код внутри фигурных скобок будет «холостым». Он определяет новую переменную под названием a и присваивает ей 42. Как только блок закончится, эта переменная выйдет из области видимости и останется старая a, до сих пор со значением 0.

Более незаметный вариант может возникнуть при опечатке в инициализации, когда вы выполняете что-то вроде этого:

int value = value + 12;

когда на самом деле ожидаете выполнение этого:

int value = othervalue + 12;

Как только компилятор распарсит int value, переменная станет валидной и будет находиться в области видимости. Вы можете считать её значение, добавить 12 к нему и присвоить результат ей же. К несчастью для вас, value, которую вы считываете, не определена. Теперь вам придется присвоить value неопределенное значение. Если вы считываете неосторожно, вы можете подумать, что проинициализировали её, хотя вы этого и не сделали. Компилятор с оптимизацией удалит +12, поскольку неопределенность плюс 12 есть неопределенность, и это будет эквивалентно следующему:

int value;

Если в вашем компиляторе есть выдача предупреждений о том, что не было проинициализировано, он должен выявить эти проблемы. К сожалению, выключение этих предупреждений происходит довольно часто, потому как в C нет способа указать выходные параметры. Вот почему следующие вещи встречаются относительно часто:

int a;
 
call_some_function(&a);

Это может и не быть ошибкой, если a используется для возвращения некоторого дополнительного значения из функции. В других случаях, функция будет считывать значение a, которая неопределенно. В компиляторе C нет способа узнать, правильно ли используется a, поэтому она может использоваться, будучи неопределенной.

Проблемы целых

Если вы используете высокоуровневые языки программирования, поддержка числовых переменных в C может показаться мучительно примитивной. То же самое может быть, если раньше вы писали на ассемблере, так как C также не открывает программисту условных кодов современных ЦПУ.

В высокоуровневых языках, числа обычно условно-точные, причем точность определена так, как вам надо. В C есть набор целых типов. Наиболее часто используемый — это int, который должен соответствовать машинному слову. На компьютерах, на которых я учил C, оно было длиной в 16 бит. Теперь он обычно размером в 32 бита, даже на архитектурах, где машинное слово имеет длину 64 бита, так как большое количество написанного кода подразумевает, что он всегда имеет длину 32 бита.

Одна из наиболее частых причин странного поведения — попытка хранить значение указателя в int. На обычных 32-битных платформах, этот метод работает хорошо. На некоторых 64-битных он работает, а на некоторых — нет. Стандарт C99 определяет новый целый тип, intptr_t, который гарантированно имеет достаточный размер, чтобы хранить указатель. Если вы планируете хранить указатель в int, вы всегда должны использовать intptr_t.

Указатель — один из других слегка сбивающих с толку моментов. C определяет два типа указателей: один указывает на код, другой указывает на данные. Указатель на функцию не имеет гарантировано такой же размер, что и указатель, указывающий на данные. На множестве встроенных платформ, часто используются 16-битные указатели для кода и 32-битные для данных. Преобразование типа в void* указателя на функцию приведет к тому, что некоторые данные будут отброшены.

Другим основным видом целого в C является char, short и long. В C99 также определен long long. Ни один из них не имеет фиксированного размера, но все они имеют минимальные размеры (технически у них есть минимальный набор значений, который они могут хранить, не предоставляя гарантий по внутреннему формату). Short должен быть, по крайней мере, 16 бит, long как минимум 32, а lon long как минимум 64. Если вам необходимо минимальное количество точности, выберите один из них, и вы сможете получить дополнительное пространство к тому, что запросили, в зависимости от архитектуры.

Я не упомянул char ещё и потому, что они детально отличаются от других типов. Все другие основные целые типы данных являются знаковыми, пока не будут объявлены, как беззнаковые. Это не всегда так в случае с char. К сожалению, в случае с char, знаковая она, или нет, полностью зависит от реализации. Если вы используете char, всегда явным образом объявляйте их как знаковые или нет, так как в противном случае, вы можете быть удивлены позднее.

В C есть несколько довольно удивительных правил для безусловных преобразований этих типов в операциях. Часто предполагают, что точность операции зависит от того, как её используют. Предположим, вы делаете следующее:

 a = b + c;

Так как вы храните результат в a, вы можете предположить, что сложение будет выполнено, каким бы типом не была a. По факту, оно будет выполнено с типом b и c. Это имеет смысл тогда, когда вы думаете, что лучше иметь значение (b + c) в зависимости от чего-то, чем b и c сами по себе. Вы можете думать, что тип этого выражения будет типом b. Стандарт C99 определяет набор правил для определения типа, но в основном он будет представлять собой тот тип, который больше, b или c. Например, если a — char, а b — int, тип выражения будет int. Поразительно часто встречается ошибка, когда делают что-то вроде такого:

long long a;
 
long b;// = чему-то
 
long c;// = чему-то
 
a = b * c;

a как минимум 64 бита, b и c как минимум 32 бита. Так как у вас есть только гарантия того, что b и c по 32 бита, вы не должны помещать нечто большее в них, даже если ваш компилятор или платформа имеет long в 64 бита. Когда вы умножаете их, вы получаете результат, подходящий для 64-битного int и вы храните его в чем-то, что подходит для 64-битного int. Звучит удобно? Так и есть, кроме того факта, что результат искажается до 32 бит прямо перед присваиванием. Вот правильный способ сделать это:

a = (long long)b * c;

Это расширяет b до 64 бит (или больше, в зависимости от реализации). Расширение типа гарантирует, что c имеет тип такого же размера, что и b, так что она также расширена. Тогда умножение происходит как умножение двух long long с 32 или более первыми нулями, а результат (long long) хранится в переменной типа long long.

В основном, вы можете избежать сюрпризов путем прямого преобразования типов к чему-то с достаточной точностью перед выполнением операции. Убедитесь, что отсутствие знака выполняется для всех переменных. Это очень частая причина ошибок, так как вы неожиданно теряете первый бит при преобразовании большого беззнакового значения к его знаковому эквиваленту.

Более неуловимая ошибка возникает от переполнения int. Она особенна часто возникает при использовании malloc, так как стандартный шаблон написания — malloc(i * sizeof(x)). Если у взломщика есть влияние на i, он может попытаться выполнить это переполнение. Для очень больших значений i, это даст результат гораздо меньший, чем i, что приведет к проблеме. Вызов malloc будет успешным, но когда вы попытаетесь использовать массив, полученный в результате, только первые несколько значений будут валидными. Взломщик может вынудить вас переписать другие данные.

Простым путем избегания этого вида уязвимости может быть использование calloc() вместо malloc() (конечно, в надежде, что реализация calloc в вашей системе производит проверку границ сама, а не просто делает malloc() и memset() для количество*размер байт).

realloc() — ещё одна проблема. Нет стандартного пути сделать это с ней, поэтому вам надо делать это самому. К счастью, OpenSSH включает в себя xrealloc(), который является версией realloc() с проверкой границ. Она включает несколько других проверок, но если вам не нужны все из них, вы можете реализовать упрощенную версию:

void * xrealloc(void *ptr, size_t nmemb, size_t size)
 
{
 
    void *new_ptr;
 
    size_t new_size = nmemb * size;
 
    if (SIZE_T_MAX / nmemb < size)
 
            return NULL;
 
        return realloc(ptr, new_size);
 
}

Этот тест довольно просто. SIZE_T_MAX — это максимальное значение, которое может иметь size_t. Когда вы делите на указанное количество элементов, вы получаете максимальный размер, который может быть без переполнения. Если этот размер меньше, чем требуемое пространство, возникает переполнение, поэтому вы возвращаете NULL.

realloc возвращает NULL в случае ошибки, так что вам всегда следует проверять возвращаемое значение realloc на валидность. К сожалению, это является наиболее частой причиной утечек памяти (которые, в свою очередь, являются причиной атак DDoS). Если realloc() возвращает NULL, исходный указатель по-прежнему является валидным. Часто разработчики забывают этот принцип и просто делают что-то вроде этого:

ptr = realloc(ptr, newsize);

Когда realloc() возвращает NULL, вы теряете вашу ссылку на предыдущее выделение памяти. FreeBSD предоставляет удобную функцию, reallocf(), которая эквивалентна следующей:

void *reallocf(void* ptr, size_t size)
 
{
 
    void *newptr = realloc(ptr, size);
 
    if (NULL == newptr)
 
    {
 
        free(ptr);
 
    }
 
    return newptr;
 
}

Если у вас нет кода для обработки случая, когда realloc() завершается с ошибкой, вам необходимо использовать что-то вроде неё.

Проблемы с памятью

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

Эта методика приводит к проблемам при передаче данных назад к вызываемой функции. Для структур очевидным решением является просто вернуть структуру. Когда она скомпилирована, вызывающая функция может выделить структуру и передать указатель к вызываемой функции, которая копирует данные в свое пространство. Тем не менее, это приводит к большому количеству копий.

Что ещё хуже, это не работает для всех динамически выделяемых данных. Рассмотрим что-нибудь, вроде sprintf(). Этот аналог printf() пишет в буфер вместо стандартного вывода. Проблема sprintf в том, что вызывающей функции необходимо знать размер буфера, что не всегда просто — на самом деле, это требует реализации большинства кода sprintf в вызывающей функции.

По факту, почти невозможно использовать sprintf безопасно. Вам необходимо указать длину каждого отдельного элемента строки формата (вот почему sprintf была создана). Это может привести к завершению процесса (что может также вызвать проблемы безопасности, и мы вернемся к этому позднее), поэтому некоторые реализации libc включают в себя asprintf().

Функция asprintf() — это то же самое, что и sprintf, кроме того, что она выделяет свой собственный буфер с помощью malloc. Это позволяет избежать досрочного завершения процесса или переполнения. К несчастью, она приносит новую проблему: когда вызывающая функция должна освобождать указатели, которые возвращает вызываемая функция?

Большое количество кода на C содержит в себе эту проблему. Решение обычно заключается в том, чтобы поместить в документацию о функции строку «вызывающая функция должна освободить возвращаемый указатель». К сожалению, этот подход делает сложной возможность взглянуть на часть кода и увидеть, валидна ли она. Одно из решений заключается в том, чтобы заключать в оболочку каждый указатель, например, так:

typedef struct _RefCountedBuffer
 
{
 
    void *buffer;
 
    int refcount;
 
    void (free*)(struct _RefCountedBuffer*);
 
} *RefCountedBuffer;

Когда вы возвращаете указатель, вы создаете одну из этих структур и устанавливаете refcount в 1. Когда вы получаете его, вы всегда вызываете функцию, которая увеличивает refcount на единицу и вызывает соответствующую функцию free(), если она достигнет нуля.

Эта методика близка для программистов Objective-C, потому как OpenStep реализует схожий механизм работы. GNUstep продвинулся дальше, предоставляя макросы ASSIGN() и DESTROY(). Эти макросы делают ошибки при работе с памятью более редкими, и мы можем сделать нечто похожее на обычном C.

Прежде всего, нам надо определить функции retain() и release():

RefCountedBuffer retain(RefCountedBuffer *buf)
 
{
 
    buffer->refcount++;
 
    return buffer;
 
}
 
void release(RefCountedBuffer *buf)
 
{
 
    buf->refcount--;
 
    if (buf->refcount == 0)
 
        buf->free(buf);
 
}

Учтите, что это упрощенные версии тех функций, что вам могут действительно потребоваться. Наиболее распространенная проблема — они не являются потоко-безопасными. Операторы ++ и — обычно компилируются в последовательность команд загрузить, добавить (или вычесть), сохранить. Если два потока, например, одновременно аккумулируют, они оба должны сначала загрузить эти значения, прежде чем сохранить их, и одна аккумуляция будет потеряна. Вы можете обойти эту проблему, используя специальный ассемблер для ЦПУ или встроенные средства GCC для элементарных операций.

Определив эти функции, вы можете определить макросы SET и FREE следующим образом:

#define SET(var, val) do { 
 
RefCountedBuffer __tmp = retain(val); 
 
if (NULL != var) release(var) var = __tmp; } while(0)

Учтите, что вы удерживаете новое значение перед освобождением старого, что может привести к проблемам в случае, если новое и старое значения равны. Соответствующий макрос FREE() довольно прост:

#define FREE(var) do { release(var) var = NULL; } while(0)

Этот макрос гарантирует, что каждый указатель всегда установлен в NULL после его освобождения. Даже если вы не используете подсчет ссылок, этот метод дает результат.

Если вы используете оба этих макроса, у вас будет очень мало знаков равенства в коде. Что делает проще просмотреть код и найти места, где могут быть ошибки, связанные с памятью.

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

Тем не менее, эта модель не решает нашу первоначальную проблему функций, похожих на asprintf. Она требует вернуть строку, что часто используется только в вызывающей функции. Для этого выделение памяти в куче и заключения её в структуру подсчета ссылок будет лишним. Вам нужен способ выделить пространство в стековом фрейме вызывающей функции.

У разработчиков сервера Dovecot IMAP есть превосходное решение. В дополнение к обычному контролю стека, они делают отдельный стек данных и аналог asprintf, которая использует его. Вызывающая функция сначала вызывает функцию, которая выделяет фрейм в новом стеке данных. Затем она вызывает аналог asprintf(), которая выделяет пространство в стеке результатов. Этот подход работает правильно, пока вызывающая функция достает верхний фрейм стека данных.

Так как контрольный стек и стек данных работают на разных скоростях, вы можете просто вернуть данные в стек данных. Пока функция, которая создала фрейм в стеке данных, также и уничтожает его, у вас не будет проблем. Работа организована таким образом, что сначала создается фрейм в стеке данных, а затем вызывается asprintf(), которая выделяет пространство в текущем фрейме стека данных и помещает результат в него. Вы используете результат, а затем выталкиваете из стека текущий фрейм.

Вам ничего не мешает иметь несколько независимых областей памяти. Вы можете использовать mmap() на /dev/zero, чтобы выделить где-либо непрерывный BLOB памяти и использовать его по своему желанию. Одной из возможных идей может быть выделение стека данных, который работает на такой же скорости, как и контрольный стек. Используйте этот метод для всех массивов, которые вы будете по-другому выделять в стеке. В отличие от контрольного стека, это может расти вверх в памяти. Вы можете сделать его переместимым, постоянно адресуя его через глобальный указатель к началу. Например, с помощью подобного макроса:

#define NEW_ARRAY(type, name, elements) 
 
__attribute__((cleanup(popDataStack)))    
 
type *name = dataStackCalloc(sizeof(type), elements)

__attribute__(cleanup) — это расширение GCC. Оно вызывает функцию popDataStack() с указателем на переменную в качестве аргумента, когда переменная выходит из области видимости. Теперь у вас есть указатель на что-то в стеке данных. Вместо использования прямого адреса, вы можете использовать макрос, который добавляет этот адрес указателю. Все это позволяет продолжать расти вашему стеку данных до тех пор, пока у вас есть достаточное количество непрерывной свободной памяти для хранения.

Как бы то ни было, вы до сих пор можете выйти за пределы массива. Вы не разрушите возвращаемый адрес, но можете переписать некоторые данные или могут возникнуть другие проблемы. Вы можете избежать выхода за пределы стека данных, вызвав функцию mprotect() на последней странице стека, чтобы удалить все права доступа. У большинства реализаций malloc() есть режим отладки, который вставляет этот вид защитной страницы после каждого выделения памяти. Вы можете сделать это, создав свой стек данных, в котором будут чередоваться доступные и недоступные страницы, с каждым выделенным массивом, так что он завершится недоступной страницей, но эта система достаточно ресурсоемка. Никакая нормальная операционная система не выделит реальную память для защитных страниц, но вы потеряете много пространства в промежутках между началами страниц и началами массивов и будете использовать большое количество адресного пространства.

Буферы и строки

Строки в C — вечная причина проблем. Когда C был создан, было две концепции о том, как лучше всего реализовывать строки — известные сейчас как строки C и строки Pascal, в соответствии с языками, которые сделали эти идеи популярными. Такие языки, как Lisp использовали третью реализацию: строки являлись связанным списком символов (Erlang до сих пор использует эту модель).

Строки в стиле Lisp имеют очевидный недостаток. Каждому символу требуется один байт для хранения символа и 4 или 8 байт для хранения адреса следующего, — до девяти байт уходит на хранение одного байта данных. Эта структура далека от идеальной, но делает разделение и конкатенацию строк очень простой.

Более совершенные модели представляют строки, как связанный список массивов символов, позволяя легко их объединять.

Все эти модели могут быть (и это было сделано) реализованы на C, но стандартные строковые функции до сих пор работают с массивами байтов.

Большинство «классических» строковых функций практически невозможно использовать безопасно (по этой причине линковщик OpenBSD легко выдает предупреждение, когда вы используете одну из них). Каноническим примером «плохой» функции является strcat(), которая принимает два указателя на строки C. Функция проходит по первой строке, пока не найдет null; она записывает туда байты из второй строки пока не дойдет до null во второй строке. Вызывающая функция должна быть уверена, что существует достаточно места в первой строке, чтобы сохранить вторую.

Более новая функция, strncat(), была создана, чтобы сделать это легче. Эта функция принимает в качестве третьего аргумента объем пространства в первой строке. Она гарантирует, что функция никогда не выйдет за пределы первой строки, но создает новую проблему: функция возвращает новую строку в качестве результата, поэтому вы не можете легко протестировать, был ли искажен результат. Это становится большой проблемой, когда соединяемые части являются, например, паролем.

В OpenBSD представлена strlcat, которая похожа на strncat, но возвращает сумму входных строк. Если результат работы функции больше третьего аргумента, имело место искажение. Эта функция находится в каждой ОС семейства BSD (включая Darwin/OS X), но её нет в glibc, так как, согласно главному разработчику glibc, является «бесполезным хламом BSD». К счастью, лицензия BSD позволяет вам копировать эту функцию из libc BSD в ваш код без каких-либо проблем.

Проблемы со строками в C велики из-за того факта, что строки — это просто массивы без проверки границ. Точно также, большинство проблем, затрагивающих строки, касаются и произвольных буферов.

Одной из самых опасных вещей в C99 является модель массивов переменной длины, которая позволяет вам выделять маленькие, с динамическим размером массивы в стеке. Вы можете всегда делать это с помощью alloca(), хотя качество реализаций alloca() варьируется между разными платформами. Следующие примерно эквивалентны:

int *a = alloca(sizeof(int) * n);
 
int a[n];

Разница в поведении, если существует недостаточно пространства для роста стека до n целых значений. Первая строка будет при этом NULL, но вы сможете проверить это, что упрощает отладку — достаточно просто обратиться к началу массива. Во второй строке, если не будет хватать размера стека, он будет указывать… куда-то. А куда именно, будет зависеть от реализации. Вот почему, если вы используете массивы C99 с переменной длиной, невозможно протестировать программу на переполнение стека. В большинстве случаев, это не является проблемой. Небольшие выделения памяти более безопасны для работы, но если взломщик сможет увеличить размер n, у вас может получиться массив, указывающий никуда.

Это является серьезной проблемой в зависимости от того, как реализован стек. В основном, нижняя часть стека является верхней границей памяти процессов, и она растет вниз. Если у вас есть массив в стеке, и вы выходите за его границы, вы перезаписываете стековый фрейм вызывающей функции. И, что ещё хуже, также перезаписываете возвращаемый адрес. Если вы используете что-то вроде strcat() с результирующей строкой в стеке, очень легко перезаписать возвращаемый адрес, позволяя взломщику контролировать, где происходит переход к выполнению, после того, как функция вернула результат.

Масштаб данной проблемы уменьшен в современных операционных системах (они проверяют целостность возвращаемого адреса и завершают процесс, если он невалиден), но это по-прежнему плохое решение. Сбои в программе лучше, чем удаленные эксплоиты, но нет ничего лучше валидного кода.

Когда все идет не так

В независимости от того, как тяжелы ваши усилия, у вас до сих пор остаются баги в коде. Разработчики OpenBSD говорят, что единственное отличие между багом и эксплойтом — интеллект взломщика, и это по большому счету, правда.

Ключом к безопасному программированию каждой части вашей программы является представление, что другая часть была написана идиотом. Вы можете проверить, что каждый входящий указатель — не NULL (хотя печально, что C не предоставляет какого-либо механизма для проверки, что он указывает на валидную часть памяти). Вы можете проверить, что любые другие значение находятся в ожидаемых вами рамках. Тем не менее, в конце концов, баг в одной части процесса может разрушить данные — а во многих операционных системах, даже код — всей остальной части процесса.

Как бы то ни было, учтите, что это касается текущего процесса. Нет никаких причин, по которым ваша программа не могла бы использовать несколько процессов. Прежде всего, безопасность и скорость работают вместе — использование нескольких процессом делают проще получение преимущество от использования нескольких процессоров.

Разбивая компоненты программы на отдельные процессы, вы ограничиваете размеры разрушений, которые может принести один баг. Самым распространенным примером является разделение привилегий кода, находящееся во множестве серверных программ. Многие сервера должны быть запущены под root, или с соответствующими правами. Им нужна эта возможность для привязки к соответствующим портам и осуществления других действий в качестве root — таких, как получения доступа к данным разных пользователей или запуск программы под другим пользователем.

Хорошим методом для такого вида процессов является заключения кода, осуществляющего привилегированные операции, в отдельный процесс. Например, если вам надо написать на разные почтовые ящики пользователей, у вас может быть процесс, который запускается под root, чтобы открыть почтовый ящик, написать в него письмо, и больше ничего. Он проверит аргументы и осуществит запись, но не более того. Это легко реализовать в коде и довольно просто найти возможные баги.

Также можно изолировать код, содержащий важную информацию. Большей части программы не надо знать, например, ключей шифрования или паролей. Вы можете хранить такую информацию в отдельном процессе и ограничивать доступ главной программы к нему, усложнив тем самым для взломщика получение доступа к этим данным.

Отказ от привилегий

Хотя разделение привилегий работает хорошо, многое может быть сделано благодаря простому отказу от привилегий. UNIX содержит семейство системных вызовов setuid(), которые позволяют процессу, запущенному в качестве root, работать как другой пользователь.

Веб-сервер нуждается в запуске в качестве root, так как ему нужно быть привязанным к 80 порту и иметь доступ к файлам в директории public_html каждого пользователя. Тем не менее, как только он привязан к 80 порту, ему не нужно более работать как root, и он может отказаться от прав root. Хотя ему по-прежнему нужен способ получать доступ к директории public_html каждого пользователя. Одно решение — заставить каждого пользователя сделать его файлы доступными для группы веб-сервера. Другим может быть выполнение fork() процесса-потомка для каждого пользователя, который работает в качестве этого пользователя и имеет доступ к файлам в директории пользователя.

Немного повысить безопасность можно, используя системный вызов chroot(), который меняет корневую директорию (которая видна процессу) на специальную директорию. Любые файлы за пределами этой директории находятся вне зоны видимости, хотя к тем, что были открыты, доступ по-прежнему остается. Этот факт важен, так как вы можете держать библиотеки и даже исполняемую программу, а также файлы настройки вне «тюрьмы» chroot.

Пользователь с правами root может легко избежать chroot, создав новое устройство для жесткого диска и смонтировав его внутрь chroot (или даже получая доступ к нему напрямую). Вот почему важно сбросить привилегии root сразу же после входа в chroot.

Ещё легче использовать chroot(), если он встроен в приложение. Команда chroot, которая запускает процесс в окружении chroot, также доступна, но этот подход имеет две проблемы. Первая — он вызывает chroot до запуска процесса, поэтому программа и все необходимые библиотеки должны быть внутри директории chroot. Вторая заключается в том, что он должен выполняться в качестве root, поэтому ему нужно что-то внутри chroot для возможности сброса привилегий. Обычным решением является поместить команду su внутрь chroot. Хотя, когда вы поместите так много кода внутрь chroot, он станет выглядеть, как и внешнее окружение.

Разгоняя ядро

Некоторые люди до сих пор считают, что конкуренция в совместно используемой памяти является хорошей моделью программирования для получения преимуществ от многоядерных процессоров. Это делает ваш код очень сложным, что увеличивает количество багов (и дыр в безопасности).

Наиболее яркий пример был недавно обнаружен в большинстве фреймворков, перехватывающих системные вызовы. Все они работали примерно следующим образом:

1. Пользовательский процесс запрашивает системный вызов.

2. Перехватывающий фреймворк проверяет валидность аргументов и решает, какой уровень привелегий должен быть у вызова (и должен ли он вообще выполняться).

3. Ядро обрабатывает вызов.

К сожалению, этот подход имеет немного неожиданное поведение. Многие системные вызовы принимают указатели в качестве аргументов. Обычно ядро отображается в адресное пространство каждого процесса (но в режиме привилегий помечается только как для чтения), поэтому обработчик системного вызова в ядре может получить доступ к тому, на что указывают эти указатели дешево (без копирования). Даже если он не может получить к ним доступ напрямую на платформах, где ядро имеет полностью отдельное адресное пространство, обычно оно так же может получать доступ к адресному пространству процесса дешево. Если вы производите системный вызов с указателем, вот добавочный шаг 2a:

2a. Другой поток изменяет данные, на которые указывает аргумент-указатель.

В этом случае обработчик системного вызова продолжает работу с чем-то, что он считает валидным, — но теперь это не так. Простейшим примером может быть системный вызов bind(), который принимает информацию о локальном адресе в качестве аргумента-указателя. Перехватывающий фреймворк сначала проверит, что вы запрашиваете для привязки к непривилегированному порту, а затем разрешит это. Это приводит к нескольким уязвимостям поднятия привилегий.

Такая же проблема возможна в коде пространства пользователя, использующего разделение привилегий, если он использует совместно используемую память. Простейшим решением будет всегда копировать текущую область памяти в привилегированный процесс перед тем, как обработать её. Эта методика хороша для небольших объемов данных, но не идеальна для более крупных. К сожалению, не существует хорошего решения этой проблемы, кроме отказа от использования совместно используемой памяти, но это обычно приводит к замедлению работы. Даже таким вещам, как конвейер требуется копирование данных в общий буфер, а затем копирование их назад из буфера. В будущем операционные системы, возможно, будут включать нечто между конвейером и буфером совместно используемой памяти, когда буфер находится в адресном пространстве получателя, но запись может быть осуществлена только ядром и разрешена, только когда получатель сообщает о том, что пространство доступно. Хотя, не похоже, что это будет осуществлено в скором времени.

Заключение

Писать безопасный код на C сложно, но это возможно. Безопасность таких систем, как OpenBSD доказывает, что это можно сделать. Язык не делает написание безопасного кода простым, но в некоторых случаях этот факт является полезным. Чтобы избежать проблем, программист должен основываться на хорошем коде, а не на возможностях языка.

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

Помимо этого решения, лучшими методами будут проверять входные значения в каждом случае, даже от источников, которым вы доверяете (вы не знаете, были ли они компрометированы и пытаются ли выполнить атаку изменения привилегий) и предпочитать аварийное завершение программы, чем попытки работать в неопределенном состоянии.

Небольшой FAQ по iptables

Разрешаем производить только 4 коннекта к 22 порту в течении 60 секунд:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP


Как удалить iptables правило по номеру

iptables -L INPUT --line-numbers
iptables -D INPUT номер
iptables -t nat -L POSTROUTING --line-numbers
iptables -t nat -D POSTROUTING номер


Как ограничить пропускную полосу для пакетов помеченных меткой через MARK

Сделать MARK, и загнать все такие трансферы в какой-либо класс шейпера. Т.е. если например помеченные пакеты — все их отнести к классу 1:51 где скорость ограничена от 32К до 64К:

tc filter add dev eth1 parent 1:0 protocol ip prio 100 handle 51 fw classid 1:51
tc class add dev eth1 parent 1:2 classid 1:51 htb rate 32Kbit ceil 64Kbit
tc qdisc add dev eth1 parent 1:51 handle 51 sfq perturb 10


Как запретить пользователям качать большие файлы
— Собираем поддержку connbytes в patch-o-matic.
— Добавляем правило в firewall, например:

iptables -A FORWARD --connbytes 100000 -j REJECT

— теперь все TCP сессии более 100 Кбайт будут «обрезаны», необходимо добавить исключения для протоколов типа ssh, обычные «долгоживущие» чаты и т.п.

Борьба с Kazaa и прочим вредным трафиком путем вырезания пакетов по маске

— собираем поддержку «string» в patch-o-matic.
— смотрим на протокол Kazaa, в заголовках содержится:

HTTP/1.0 503 Service Unavailable.Retry-After: 3..X-Kazaa-Username: BlazeTre

— добавляем в firewall строчку — iptables -A FORWARD -m string —string «X-Kazaa-» -j REJECT

Как в Linux перебросить соединение через NAT во внутреннюю сеть (1)

Первый путь — пробрасывание только порта:

1) iptables -t nat -A PREROUTING -p tcp -d EXT_R_IP --dport 10000 -j DNAT --to-destination LOCAL_IP:80
2) iptables -A FORWARD -i eth0 -d LOCAL_IP -p tcp --dport 22 -j ACCEPT

Второй вариант — выброс всей машины наружу (если есть свободные адреса):

1) ifconfig eth0:0 NEW_IP netmask NETMASK broadcast BROADCAST
2) route add NEW_IP gw GW netmask 0.0.0.0 metric 1 dev eth0:0
3) iptables -t nat -A PREROUTING -p tcp -d NEW_IP -j DNAT --to-destination LOCAL_IP
4) iptables -A FORWARD -i eth0 -d LOCAL_IP -j ACCEPT

Обозначения: EXT_R_IP — внешний IP роутера, LOCAL_IP — внутренний IP машины, которую хочешь выбросить NEW_IP — новый IP на который хочешь посадить машину, которая имеет локальный LOCAL_IP NETMASK, BROADCAST, GW — внешние netmask, broadcast и gateway


Пример настройки NAT с привязкой к IP под Linux

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -o eth0 -j SNAT --to-source 212.23.98.45

или (без привязки к IP)

ipchains -A forward -j MASQ -s 192.168.0.0/16 -d 0.0.0.0/0

или (через iproute2)

ip rule add from 10.0.1.0/24 nat 254.147.38.14

Другой способ трансляции адресов:<

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -j MASQUERADE


Как ограничить через iptables максимальное число одновременных соединений с одного IP.

# Максимум 10 одновременных соединений к 80 порту с одного IP
iptables -A INPUT-p tcp --dport 80 -m iplimit --iplimit-above 10 -j REJECT
# Блокируем на стадии SYN
iptables -I INPUT -p tcp --syn --dport 80 -j DROP -m iplimit --iplimit-above 10
# 20 соединений на сеть класса С
iptables -p tcp --dport 80 -m iplimit --iplimit-above 20 --iplimit-mask 24 -j REJECT


Как посмотреть статистику по PREROUTING цепочкам в iptables.
> Делаю: >

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128 &gt;

По iptables -L ничего не показывается.
Используйте:

iptables -t nat -L


Как настроить пакетный фильтр для фильтрации по содержимому пакетов
Следующие правила блокируют прохождение пакетов, данные в которых содержат подстроку virus.exe и ведут лог пакетов с строкой secret внутри:

iptables -A INPUT -m string --string "secret" -j LOG --log-level info --log-prefix "SECRET"
iptables -I INPUT -j DROP -p tcp -s 0.0.0.0/0 -m string --string "virus.exe"
# Block Code Red
iptables -I INPUT -j DROP -p tcp -m string --string "cmd.exe"
# Block Nimda
iptables -I INPUT -j DROP -p tcp -m string --string "root.exe"
iptables -I INPUT -j DROP -p tcp -m string --string "default.ida"


Как настроить NAT (транслятор адресов) для нормальной работы с FTP и ICQ в Linux
iptables:

modprobe iptable_nat
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
modprobe ip_nat_irc

ipchains:

modprobe ip_masq_ftp
modprobe ip_masq_raudio
modprobe ip_masq_irc
modprobe ip_masq_icq


Можно ли отфильтровывать пакеты (вести лог) в зависимости от UID пользователя ?>
Для FreeBSD:

ipfw add count tcp from any to not 192.168.1.0/24 uid 231

uid user (или gid group) — под правило попадают все TCP или UDP пакеты посланный или принятые пользователем user (группой group).
В Linux в ядрах 2.4.x в iptables можно использовать модуль owner.

Ограничение трафика через iptables (1)

iptables --new-chain car
iptables --insert OUTPUT 1 -p tcp --destination-port 25 -o eth1 --jump car
iptables --append car -m limit --limit 20/sec --jump RETURN
iptables --append car --jump DROP

Источник

Советы по работе с DNS зонами

Чтобы было наглядней о чем разговор идет, опишу как происходит процесс делегирования. Делегирование — это то каким образом пространство имен в DNS делится на зоны. Зона — это обособленная ветвь пространства DNS имен которая располагается на своих авторитарных DNS серверах. В зону может входить любое количество доменов нижележащего уровня — до тех пор пока они все расположены на одних и тех же авторитарных серверах, зона у них одна и та же.
Делегирование из родительской зоны происходит путем создания NS записей. В дочерней (делегированной) зоне создается полное описание зоны начиная с SOA записи. Вот, например, когда регистрируется домен второго уровня через регистратора nic.ru, то там при регистрации просят указать имена и адреса минимум двух DNS серверов которые будут считаться авторитарными для данной ветви пространства DNS имен. Для проведения делегирования не обязательно иметь под зону именно два DNS сервера — просто у nic.ru такая политика для того чтобы заставить клиентов обеспечить надежность системы. Вот эти два сервера становятся NS записями в домене ru.

Пример. Скажем, нами регистрируется домен второго уровня под названием net.ru. Авторитарными для него будут DNS сервера ns.net.ru (IP 1.2.3.4) и ns2.dnshosting.com (IP 5.6.7.9). В записях DNS серверов отвечающих за зону ru. (которыми управляет организация nic.ru) вносится такая информация:

$TTL 300
ru.   IN   SOA   ns.ripn.net. hostmaster.ripn.net. (
         4014396 ;serial
         7200   ;refresh
         900   ;retry
         2592000   ;expire
         3600   ;neg. ttl
         )
      NS   sunic.sunet.se.
      NS   e.dns.ripn.net.
      NS   ns.ripn.net.
      NS   ns5.msk-ix.net.
 
; это добавили
net.ru.   NS   ns.net.ru.
net.ru.   NS   ns2.dnshosting.com.
ns.net.ru.   A   1.2.3.4

Запись «ns.net.ru. A 1.2.3.4» называют еще «glue record», она нужна в случаях, когда имя NS сервера располагается внутри делегированной зоны. Это вспомогательная запись которую обязательно указывать в таких случаях. Без нее возникла бы ситуация, когда для того чтобы узнать IP сервера ns.net.ru надо обратиться к нему по IP (замкнутый круг). Так как второй NS расположен в чужой зоне, то для него не указываем glue record.

В свою очередь на сервере ns.net.ru который является мастером для зоны net.ru создается полная SOA запись как и полагается:

$TTL 300
net.ru.   IN   SOA   ns.net.ru. hostmaster.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
      MX 10   mail.net.ru.
ns.net.ru.   A   1.2.3.4
 
www.net.ru.   A   9.8.7.6
ftp.net.ru.   A   10.11.12.13
mail.net.ru.   A   11.12.13.14

На slave сервере ns2.dnshosting.com в ручную записи не создаются, но он настраивается так чтобы периодически запрашивать мастер ns.net.ru и перекачивать с него всю информацию о записях в домене, а мастер ns.net.ru настраивается так чтобы отдавать все записи о зоне при запросах с подчиненного.

Точно по такой же схеме происходит делегирование доменов третьего, четвертого да любого уровня. Делегировать можно даже одно единственное хост имя!

Например случай с делегированием домена третьего уровня. Выглядеть это будет так — в записях зоны net.ru добавляется информация с NS записями о субдомене home.net.ru (допустим, будет только один авторитарный DNS сервер для этого субдомена ns.home.net.ru IP 7.7.7.7)

$TTL 300
net.ru.   IN   SOA   ns.net.ru. hostmaster.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
      MX 10   mail.net.ru.
ns.net.ru.   A   1.2.3.4
 
www.net.ru.   A   9.8.7.6
ftp.net.ru.   A   10.11.12.13
mail.net.ru.   A   11.12.13.14
 
;это добавили
home.net.ru.   NS   ns.home.net.ru.
ns.home.net.ru.   A   7.7.7.7

Ну и соответственно на DNS сервере ns.home.net.ru создается зона с новой SOA записью:

$TTL 300
home.net.ru.   IN   SOA   ns.home.net.ru. adminzoni.mail.ru. (
         2009012501   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.home.net.ru.
ns.home.net.ru.   A   7.7.7.7
 
home.net.ru.      A   7.7.7.8
www.home.net.ru.   A   7.7.7.8
proxy.home.net.ru.   A   7.7.7.9

Был приведен синтаксис зоны как это принято в BIND и NSD. Для djbdns то, что написано выше будет выглядеть так:

Zhome.net.ru:ns.home.net.ru.:adminzoni.mail.ru.: \
2009012501:7200:900:2592000:3600:300
&amp;home.net.ru:7.7.7.7:ns.home.net.ru
+home.net.ru:7.7.7.8:300
+www.home.net.ru:7.7.7.8:300
+proxy.home.net.ru:7.7.7.9:300

До кучи, напишу заодно еще и про реверс зоны и их делегирование.
Система DNS позволяет производить обратные разрешения из IP адресов в DNS имена. Для этого в дереве имен есть специальный служебный домен под именем in-addr.arpa. Этот домен имеет 256 субдоменов, каждый из субдомменов может иметь 256 своих субдоменов, у которых могут быть 256 своих субдоменов, в которых уже будет по 256 имен. Таким образом получается структура вида a.b.c.d.in-addr.arpa. где а,b,c,d это 0-255. На эту часть DNS имен распространяются те же правила, что и на обычные имена, вот только владельцем какого-либо субдомена может стать лишь организация получившая контроль за соответствующим блоком IP адресов — например провайдер, когда покупает для своих нужд у RIPE диапазоны IP адресов. Например, если провайдер купил себе префикс с адресами 123.44.55.0/24 (256 адресов), то он может получить от RIPE (регионального регистратора) и реверс зону в которой начнет создавать PTR записи по просьбе клиентов или для своих нужд:

$TTL 300
55.44.123.in-addr.arpa.   IN   SOA   ns.net.ru. admin.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
 
1.55.44.123.in-addr.arpa.   PTR   hostname.net.ru.
2.55.44.123.in-addr.arpa.   PTR   imja.net.ru.
254.55.44.123.in-addr.arpa.   PTR   esheodnoija.net.ru.

Тут все просто и красиво потому, что в этом примере деление на DNS зону и IP субнет произошло по границе третьего и четвертого байта в IP адресе, а как делегировать половину субнета или только пару IP адресов из него? Скажем, клиент купил себе 8 «белых» IP адресов и захотел получить контроль над назначением реверс имен для них?
В таком случае можно сделать делегирование таким образом — в родительской зоне создаются CNAME записи на подставной домен, а он уже делегируется клиенту:

$TTL 300
55.44.123.in-addr.arpa.   IN   SOA   ns.net.ru. admin.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
 
1.55.44.123.in-addr.arpa.   PTR   hostname.net.ru.
2.55.44.123.in-addr.arpa.   PTR   imja.net.ru.
254.55.44.123.in-addr.arpa.   PTR   esheodnoija.net.ru.
 
;создаем подставные записи
7.55.44.123.in-addr.arpa.   CNAME   7.klient.55.44.123.in-addr.arpa.
8.55.44.123.in-addr.arpa.   CNAME   8.klient.55.44.123.in-addr.arpa.
9.55.44.123.in-addr.arpa.   CNAME   9.klient.55.44.123.in-addr.arpa.
10.55.44.123.in-addr.arpa.   CNAME   10.klient.55.44.123.in-addr.arpa.
11.55.44.123.in-addr.arpa.   CNAME   11.klient.55.44.123.in-addr.arpa.
12.55.44.123.in-addr.arpa.   CNAME   12.klient.55.44.123.in-addr.arpa.
13.55.44.123.in-addr.arpa.   CNAME   13.klient.55.44.123.in-addr.arpa.
14.55.44.123.in-addr.arpa.   CNAME   14.klient.55.44.123.in-addr.arpa.
 
;делегируем клиенту
klient.55.44.123.in-addr.arpa.   NS   ns1.klient.ru.
klient.55.44.123.in-addr.arpa.   NS   ns2.hosting.com.

Клиент принимает у себя:

$TTL 300
klient.55.44.123.in-addr.arpa.   IN   SOA   ns.klient.ru. admin.klient.ru. (
         2009012502   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.klient.ru.
      NS   ns2.hosting.com.
 
7.klient.55.44.123.in-addr.arpa.   PTR   host1.klient.ru.
8.klient.55.44.123.in-addr.arpa.   PTR   host2.klient.ru.
9.klient.55.44.123.in-addr.arpa.   PTR   host3.klient.ru.
10.klient.55.44.123.in-addr.arpa.   PTR   host4.klient.ru.
11.klient.55.44.123.in-addr.arpa.   PTR   host5.klient.ru.
12.klient.55.44.123.in-addr.arpa.   PTR   host6.klient.ru.
13.klient.55.44.123.in-addr.arpa.   PTR   host7.klient.ru.
14.klient.55.44.123.in-addr.arpa.   PTR   host8.klient.ru.
 
...

Да, еще одна штука вспомнилась.
Я когда работал в провайдере, так все хотел приколоться и сделать себе почтовый адрес вида terminus@1.2.3.4.in-addr.arpa, но не успел — все лень было, а потом уволился и сейчас своих реверс зон нет нигде.

Между прочим, нету никакаих объективных причин почему бы такое не работало — DNS должен будет корректно отвечать на запросы о MX записях для домена 1.2.3.4.in-addr.arpa так же как и для обычных доменов. Если есть в наличии SMTP сервер «для поиграться» + желание приколоться, то можно прописать в PTR зоне MX запись, на почтовом сервере на который указывают MX запись прописать домен, и проверить как оно будет (99% что должно работать).

Источник

Быстрое обновление и восстановление портов

Содержание:

Введение.

1. Скачивание и установка дерева портов.
2. Обновление и исправление базы данных портов.
3. Редактирование /etc/make.conf (оптимизация, etc).
4. Простое обновление.
5. Полезные опции portupgrade.
6. Простой скрипт обновления.
7. Скрипт обновления, усовершенствованный (Рекомендуемый).
8. Скрипт автоматического обновления (экспериментально).
9. Исправление некоторых проблем.

Введение

если нужно обновить (и(или)восстановить) порты, может быть запутанная ситуация (например, если не обновлять год), portupgrade очень часто с первого раза не исправляет ошибки

OS: FreeBSD 7.0, FreeBSD 7.1, FreeBSD 8.0

1. Скачивание и установка дерева портов.

для начало перейти в:

cd /usr

скачаем архив дерева портов, это будет быстрее чем обновлять через cvsup, ищем ближайщый ftp провайдера/города/страны

качаем:

wget 'ftp://ftp2.ua.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz'

перед скачиваем нужно обратить внимание чтобы архив был создан не позже чем 1-2 дня назад (желательно), некоторые ftp редко синхронизируются!

rm -rf /usr/ports

можно не большой скрипт который быстрее разархивирует:

#!/usr/bin/perl
 
open (OPEN, "tar -tf ports.tar.gz |");
 
while (my $p = ) {
system("tar -xvzf ports.tar.gz $p &gt; /dev/null &amp;");
}
 
close OPEN;

(если perl не стоит, то скорее всего он будет из мира, по-моему путь #!/usr/local/bin/perl )

PS вообще-то, portsnap лучше, чем архив качать и еще есть rsyns

2. Обновление и исправление базы данных портов.

бэкап базы пакетов:

cp /var/log/dpkgdb.db /home/dpkgdb.db

можно заархивировать каталоги /etc/ /usr/local/etc программа может затереть конфиг (осторожно с символическими ссылками чтобы не удалить случайно важную информацию)

pkgdb -aF

-a all, -F исправлять не спрашивая, считается безопасный метод
если база сбита, то на крайняк можно pkgdb -fu

3. Редактирование /etc/make.conf (оптимизация, etc).

по-моему: в FreeBSD 7.2, FreeBSD 8.0 CURRENT) в CFLAGS присутствует скрытый дефект: -ffast-math, который оборачиваектся для нас -funsafe-math-optimizations -fno-math-errno http://www.freebsd.org/cgi/query-pr.cgi?pr=137869
будьте внимательны

ee /etc/make.conf
 
WITCH=BATCH=yes # не выдавать окно в котором спрашивать с чем компилировать
BATCH=yes
 
# параллельная сборка портов, появилась с FreeBSD 7.2 лучше  не включать
#
# MAKE_JOBS_SAFE=yes
# MAKE_JOBS_NUMBER=8
# FORCE_MAKE_JOBS=yes
# DISABLE_MAKE_JOBS=yes
# MAKE_JOBS_UNSAFE=yes
 
# FORCE_MAKE_JOBS=
#MAKE_JOBS_NUMBER!= let $$(sysctl -n kern.smp.cpus) \* 4
#
#.for port in \
#        emacs-devel cross-binutils libgpg-error perl5.8 libthai \
#        libiconv m17n-lib nasm tightvnc db47 subversion* \
#        ghostscript8 pth cdrtools* w3m* xmp libslang2 ezm3 dcget libxml2 \
#        vim gperf ffcall ORBit2 py-gtk2 xkeyboard-config ruby18 clisp \
#        jdk16 p7zip zsh libsndfile openjdk6 gettext stumpwm
#
#. if ${.CURDIR:M*/${port}}
#    MAKE_JOBS_UNSAFE=
#. endif
#.endfor
#
 
# оптимизация
# CPUTYPE=pentium4 # архитектура
# CFLAGS+=-g
# CFLAGS=-O2 -pipe -ffast-math -funit-at-a-time -fpeel-loops -ftracer
# -funswitch-loops -mmmx -msse -msse2 -march=pentium4 -mtune=pentium4
# COPTFLAGS=-O2 -pipe  -ffast-math -funit-at-a-time -fpeel-loops -ftracer
# -funswitch-loops -mmmx -msse -msse2 -march=pentium4 -mtune=pentium4
# CXXFLAGS+=-fconserve-space
# NO_PROFILE=true
# LOCALIZED_LANG=ru
 
CPUTYPE=pentium4 # архитектура
CFLAGS=-O2 -pipe -funit-at-a-time -fpeel-loops -ftracer
-funswitch-loops -mmmx -msse -msse2 -march=pentium4 -mtune=pentium4
COPTFLAGS=-O2 -pipe -funit-at-a-time -fpeel-loops -ftracer
 -funswitch-loops -mmmx -msse -msse2 -march=pentium4 -mtune=pentium4
CXXFLAGS+=-fconserve-space
NO_PROFILE=true
LOCALIZED_LANG=ru
 
# зеркало (указать свои)
 
MASTER_SITE_OVERRIDE?= \
ftp://ftp5.ua.FreeBSD.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ \
ftp://ftp7.ua.FreeBSD.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ \
ftp://ftp.ua.FreeBSD.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ \
ftp://ftp.gentoo.org.ua/distfiles/${DIST_SUBDIR}/ \
ftp://ftp2.ua.FreeBSD.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ \
ftp://ftp6.ua.FreeBSD.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ \
ftp://ftp8.ua.FreeBSD.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ \
ftp://ftp.linux.kiev.ua/pub/Linux/Gentoo/distfiles/${DIST_SUBDIR}/ \
ftp://ftp.lucky.net/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR} \
ftp://ftp3.ua.freebsd.org/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/ \
ftp://ftp4.ua.freebsd.org/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/ \
ftp://ftp.ntu-kpi.kiev.ua/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ \
ftp://ftp.univ.kiev.ua/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ \
ftp://ftp.univ.kiev.ua/pub/OS/FreeBSD/distfile/${DIST_SUBDIR} \

4. Простое обновление.

если portupgrade не стоит, то поставить:
(потянет ruby)

cd /usr/ports/sysutils/portupgrade &amp;&amp; make &amp;&amp; make install &amp;&amp; make clean

в headbook’е написано:

portupgrade -a

в других источниках сразу, рекомендуют:

portupgrade -arR

чтобы пройтись вдоль всех зависимостей

5. Полезные опции portupgrade.

полезные опции в portupgrade:
-W не чистить порт после обновления;
-w не чистить порт перед обновлением;
-F для того что скачать все исходники сразу, если проблемы с интернетом: portupgrade -aFrR
опции -f устанавливает дальше все зависимости, если даже где-то ошибка, то пытается продолжить дальше…;
-l /var/log/pport.log — записывает последнюю ошибку;
-L %s::%s создает файл в текущем каталоге, в котором записывает весь вывод установленных портов.

2 полезные команды make:
1) cd /usr/ports/deve/icu && make run-depends-list покажет зависимости данного порта,
2) make all-depends-list — все зависимости и зависимости тех портов которые зависят от порта

есть один важный недостаток, бывает версия порта называется не совсем корректно, например cairo-1.8.6_1,1 и portupgrade может всегда писать что порт устаревший

6. Простой скрипт.

portupgrade -arR часто тоже может выдаст ошибку!!
есть вариант написать скрипт, который обновит те порты который устаревшие в месте с зависимостями:

#!/usr/bin/perl
 
$nn = 0;
 
while (1) {
 
    $nn++;
 
    open( OPERN, "portversion |" );
 
    @all = ;
 
    if ( $nn &gt; 6 ) {
    print "while 6 exit";
    exit;
    }
 
    foreach (@all) {
 
        my ( $pp, $st ) = split( / /, $_, 2 );
 
        if ( $st =~ '&lt;' ) {
 
            print "UPDATE: $pp\n";
 
            system("portupgrade -f $pp");  
 
        } else {
            print "ok UPDATE";
            exit;
        }
    }
 
}

при этом может быть очень часто что что-то пропустит из-за подзависимоти каких-то скорее всего, цикл идет в 2 этапов if ( !$nn > 2 )

если порты запутанные, можно написать чтобы обновляло и новую версия как не корректную if ( $st =~ ‘<‘ || $st =~ ‘>’) {

Важное примечание: при обновлении Desktop лучше сначала попробовать portupgrade -aRr, так как опция -R (portupgrade -Rf $all[0] для скрипта ниже) (ее lissyara рекламировал) будет устанавливать все зависимости по новому, если нужно обновить, к примеру, 4 программы evince/firefox3/xfce4, то они потянут около 20-60 зависимостей каждая (не считал), и одно и тоже portupgrade будет собирать (но имейте ввиду что эта опция -R надежная), более «мягче» есть вариант в данном случае поставить portupgrade -rf ports_old, при этом будут собираться только «ближайшие» зависимости, самый жесткий вариант portupgrade -Rrf ports_old скорее всего лучше использовать в редких случаях, например, если не хочет компилироваться /devel/icu, так же можно просто -f.

перед кажой установленной программой желательно пересмотреть еще раз список устаревших портов, чтобы не компилировать одно и тоже лишный раз, так как с опциями -R или -r многое уже может быть обновленно, portversion быстро смотрит какие версии установлены…

7. Скрипт обновления, усовершенствованный (Рекомендуемый).

вот маленький скрипт для этого + еще реализовал запись в лог файл, чтобы было видно какой порт обновляется и сколько время прошло:

#!/usr/bin/perl
 
$nn = 0;
 
while (1) {
 
    $nn++;
 
    open( OPERN, "portversion |" );
 
    my @all2 = ;
 
    close OPERN;
 
    my @all;
 
    for ( $i = 0 ; $i &lt; @all2 ; $i++ ) {
 
        my ( $pp, $st ) = split( / /, $all2[$i], 2 );
        if ( $st =~ '&lt;' ) {
 
            push @all, $pp;    # $all[$i] = $pp;
 
        }
 
    }
 
    exit if ( !$all[0] || $nn &gt; 2 );
 
    while (1) {
 
        last if !$all[0];
 
        print "$all[0]\n";
 
        logsave( get_time(), $all[0] );
 
        system("portupgrade -rf $all[0]");
      # system("portupgrade -Rf $all[0]");
 
      # первый порт попробовать обновить вдоль и поперек
      # (выше system нужно закомментировать)
      # if ($nn == 1) {
      #  system("portupgrade -rRf $all[0]");
      #  } else {
      #  system("portupgrade -rf $all[0]");
      #  }
 
   #  экспериментально:
   #  можно добавить чтобы скрипт автоматически нажимал на энтер
   #    use IO::Select;
   #     my $select = IO::Select-&gt;new;
   #    for(@array)
   #     open my $pipe, "|$_";
   #     $select-&gt;add($pipe);
   #    }
   #    my @waiters = $select-&gt;can_write($timeout);
   #    print $_ "\x0a" for @waiters; 
 
        logsave( get_time(), $all[0] );
 
        shift @all;
 
        my @all = old(@all);
 
    }
 
}
 
sub old {
 
    my @all = @_;
 
    open( OPEN2, "portversion |" );
 
    my @all_all = ;
 
    close OPEN2;
 
    my @old;
    my @no_old;
 
    foreach my $p (@all_all) {
 
        my ( $pname, $status ) = split( / /, $p, 2 );
 
        if ( $status =~ '&lt;' ) {
 
            push @old, $pname;
 
        }
        else {
            push @no_old, $pname;
        }
    }
 
    my %seen;
    @seen{@all} = ();
    delete @seen{@no_old};
    return keys %seen;
 
}
 
sub get_time {
    my ( $sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst ) =
      localtime(time);
    $mon++;
    $year += 1900;
    if ( $mday &lt; 10 ) { $mday = "0$mday"; }
    if ( $mon &lt; 10 )  { $mon  = "0$mon"; }
    if ( $min &lt; 10 )  { $min  = "0$min"; }
    my $date        = "$mday $mon $year";
    my $time        = "$hour:$min:$sec";
    my $cur_all_day = $mday + $mon * 30 + $year * 365;
    my $radate      = "$year-$mon-$mday $hour:$min:$sec";
    return $radate;
}
 
sub logsave {
    my ( $time, $ports ) = @_;
    my $logfile;
    $logfile = "\n time:  $time \n  ports: $ports \n\n";
    system("touch /var/log/portupgrade.log");
    open( DB2, "/var/log/portupgrade.log" ) || die "Cannot open file: $!";
    my @base = ;
    close(DB2);
    open( DB, "&gt;/var/log/portupgrade.log" ) || die "Cannot open file : $!";
    print DB @base;
    print DB $logfile;
    close(DB);
}

8. Скрипт автоматического обновления (экспериментально).

дальше я написал простейший скрипт для автоматического обновления, который обновит дерево портов и порты через cron, отправит на email какие порты он обновил, и какие были устаревшие, можно поставить раз в неделю в cron

нужно заменить email адрес на тот который будет отсылаться Вам, и проверить работоспособность ftp с которого архив порта скачать

#!/usr/bin/perl
 
system("rm -rf /usr/ports.tar.gz");
 
system(
"cd /usr &amp;&amp;
wget ftp://ftp2.ua.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz");
 
system("rm -rf /usr/ports");
 
open( OPEN, "tar -tf /usr/ports.tar.gz |" );
 
while ( my $p =  ) {
    system("tar -xvzf /usr/ports.tar.gz /usr/$p &gt; /dev/null &amp;");
}
 
close OPEN;
 
my $db = '/home/pkgdb.db' . time;
 
system("cp /var/db/pkg/pkgdb.db  $db");
 
system("pkgdb -aF");
 
my $etc       = '/home/etc' . time;
my $etc_local = '/home/etc_local' . time;
 
system("tar -cf $etc /etc");
system("tar -cf $etc_local /usr/local/etc");
 
open( OLD, "portversion -F|" );
my @all_old =
;
close OLD;
 
foreach (@all_old) {
    my ( $pname, $status ) = split( / /, $_, 2 );
    push @old, $pname if ( $status =~ '&lt;' );
}
 
$nn = 0;
 
while (1) {
 
    $nn++;
 
    open( OPERN, "portversion |" );
 
    my @all2 = ;
 
    my @all;
 
    for ( $i = 0 ; $i &lt; @all2 ; $i++ ) {
 
        my ( $pp, $st ) = split( / /, $all2[$i], 2 );
        if ( $st =~ '&lt;' ) {
 
            push @all, $pp;    # $all[$i] = $pp;
 
        }
 
    }
 
    exit if ( !$all[0] || $nn &gt; 2 );
 
    while (1) {
 
        last if !$all[0];
 
        print "$all[0]\n";
 
        system("portupgrade -rf $all[0]");
 
        shift @all;
 
        my @all = old(@all);
 
    }
 
}
 
sub old {
 
    my @all = @_;
 
    open( OPEN2, "portversion |" );
 
    my @all_all = ;
 
    my @old;
    my @no_old;
 
    foreach my $p (@all_all) {
 
        my ( $pname, $status ) = split( / /, $p, 2 );
 
        if ( $status =~ '&lt;' ) {
            push @old, $pname;
        }
        else {
            push @no_old, $pname;
        }
    }
 
    my %seen;
    @seen{@all} = ();
    delete @seen{@no_old};
    return keys %seen;
 
}
 
open( NEW, "portversion -F|" );
my @all_new = ;
close NEW;
 
foreach (@all_new) {
    my ( $pname, $status ) = split( / /, $_, 2 );
    push @new, $pname if ( $status =~ '&lt;' );
}
 
open( SENDMAIL, "|/usr/local/sbin/sendmail -t" )
  or die "sendmail not ready";
print SENDMAIL "From: FreeBSD \n";
print SENDMAIL "Reply-To: FreeBSD
\n";
print SENDMAIL "Subject: UPDATE from portupgrade\n\n";
print SENDMAIL "list old\n\n";    #
print SENDMAIL "@old\n\n";
print SENDMAIL "list new\n\n";
print SENDMAIL "@new\n\n";
print SENDMAIL "#################\n";
print SENDMAIL "list ALL old\n\n";    #
print SENDMAIL "@all_old\n\n";
print SENDMAIL "list ALL new\n\n";
print SENDMAIL "@all_new\n\n";
close(SENDMAIL) or warn "sendmail didn`t close nicely";

пример как можно написать что-то подобное portupgrade:

#!/usr/bin/perl
 
open( OPEN2, "portversion -o  |" );
 
@all_all = ;
 
my @all;
 
foreach (@all_all) {
    my ( $pname, $status ) = split( / /, $_, 2 );
    $pname = '/usr/ports/' . $pname;
    $pname =~ s/^\s+//;
    $pname =~ s/\s+$//;
    push @all, $pname;
}
 
my $port;
 
my @old;
my @no_old;
 
foreach my $p (@all_all) {
 
    my ( $pname, $status ) = split( / /, $p, 2 );
 
    if ( $status =~ '&gt;' || $status =~ '&lt;' ) {
 
        $pname = '/usr/ports/' . $pname;
        $pname =~ s/^\s+//;
        $pname =~ s/\s+$//;
        push @old, $pname;
 
    }
    else {
        $pname = '/usr/ports/' . $pname;
        $pname =~ s/^\s+//;
        $pname =~ s/\s+$//;
        push @no_old, $pname;
    }
 
}
 
@to_port = `cd $old[0] &amp;&amp; make all-depends-list`;
 
foreach (@to_port) {
    $_ =~ s/^\s+//;
    $_ =~ s/\s+$//;
}
 
my %seen;
@seen{@to_port} = ();
delete @seen{@no_old};
@dep2 = keys %seen;
 
print "@dep2\n";

9. Исправление некоторых проблем.

если обновилось php, то нужно обновить его библиотеки:

pkg_info  | grep '^php5*' | awk '{print $1}' | xargs portupgrade -f
|| pkgdb -fFu &amp;&amp; portsclean -CLPP

для perl часто тоже может понадобиться:

pkg_info  | grep '^p5-*' | awk '{print $1}' | xargs portupgrade -f
|| pkgdb -fFu &amp;&amp; portsclean -CLPP

так же есть скрипт perl-after-upgrade

Java (jdk*) прийдеться руками ставить

очистить порты и каталог distfile:

portsclean -CDD

Источник

Символьные ссылки в Windows

Под ссылками в Windows я понимаются ссылки в NTFS. В FAT механизмов ссылок предусмотрено не было.

Ядро Windows поддерживает следующие виды ссылок:

  • Hard Links — жёсткие ссылки, как в *nix. Доступны начиная с Windows NT4;
  • Junction Points — аналог символических ссылок. Доступен начиная с Windows 2000 (NTFS 5);
  • Symbolic Links — символьные ссылки. Доступны начиная с Windows Vista.

Если вы никогда не имели дела с символическими и жёсткими ссылками, но хотели бы узнать о них, советую прочитать отрывок из документации файлового менеджера FAR:

Жесткие и символические связи

На разделах NTFS также можно создавать жесткие (HardLink) связи для файлов и символические (SymLink) для папок с помощью команды Alt-F6.

Жесткие связи применяются для файлов. Символические связи — для папок и дисков.

Жесткие связи

Жесткая связь (HardLink) — это просто еще одна запись в папке для данного файла.

Когда создается жесткая связь, сам файл не копируется физически, а только появляется под еще одним именем или в еще одном месте, а его старые имя и местонахождение остаются нетронутыми. С этого момента жесткая связь неотличима от первоначальной записи в папке. Единственное отличие — то, что для жесткой связи не создается короткое имя файла, поэтому из программ ДОС она не видна.

Когда меняется размер или дата файла, все соответствующие записи в папках обновляются автоматически. При удалении файла он не удаляется физически до тех пор, пока все жесткие связи, указывающие на него, не будут удалены. Порядок их удаления значения не имеет. При удалении жесткой связи в корзину количество связей у файла сохраняется.

FAR умеет создавать жесткие связи, отображать количество жестких связей для каждого файла в отдельной колонке (по умолчанию это последняя колонка в 9-м режиме панелей), а также сортировать файлы по количеству жестких связей.

Жесткие связи поддерживаются в NTFS, начиная с NT 4.0. Создавать жесткие связи можно только на том же диске, на котором расположен исходный файл.

Символические связи

NTFS начиная с версии 5.0 (Windows 2000/XP) поддерживает символические связи (SymLink). Символические связи папок в Windows 2000/XP известны как «directory junctions» — технология, позволяющая отображать любые локальные папки на любые другие локальные папки. Например, если папка D:\SYMLINK указывает на C:\WINNT\SYSTEM32 в качестве своей цели, то программа, обращающаяся к D:\SYMLINK\DRIVERS, будет на самом деле обращаться к C:\WINNT\SYSTEM32\DRIVERS.

FAR умеет создавать символические связи только на локальных дисках, файловая система которых поддерживает эту возможность (Windows 2000/XP/NTFS 5.0). В отличие от жестких связей, символические связи не обязательно должны указывать на тот же диск.

Напрямую делать символические связи на папки CD-ROM нельзя, но можно это ограничение обойти, смонтировав CD-ROM диск на папку NTFS-раздела.

Там говорится только о Hard Links и Junction Points, но этого вполне достаточно. Symbolic Links действуют так же, как и Junction Points, с той разницей, что могут указывать на файлы (и реализованы в Windows по-другому).

Hard Links можно создавать только на файлы, Junction Points — только на директории, Symbolic Links — на файлы и директории. В дальнейшем под «жёсткими ссылками» подразумеваются Hard Links, под «символьными» — Junction Points и Symbolic Links.

Жёсткие ссылки действительны в пределах одного раздела, символьные — могут пересекать границы разделов. В связи с этим символьные ссылки могут поломаться, если структуру разделов поменять.

Не со всем, что поддерживается ядром, умеет нормально работать эксплорер. Будьте осторожны при использовании Junction Points в версиях Windows до Vista. При удалении Junction Point эксплорер может залезть внутрь директории, на которую ссылается Junction Point и поудалять там всё, а затем удалить Junction Point, хотя должен лишь удалить ссылку. Наверняка могут возникнуть проблемы и при перемещении или копировании Junction Point’ов.

Мне неизвестно, нормально ли в версиях Windows до Vista относятся к Junction Points стандартные утилиты типа rmdir.

Дополнительные материалы по теме

Отмечу англоязычную статью, в которой описаны нюансы использования ссылок и некоторые программы, позволяющие с ними работать. Статья устаревшая, так что в ней говорится только о Hard Links и Junction Points (причём на последние в статье нередко ссылаются, как на symbolic links…).

Хорошее описание всех видов ссылок есть ещё в справке по NTFS Links (дополнение для Total Commander).

Софт

Теперь можно перейти к рассмотрению программ для работы со ссылками. Да-да, если вы не пользуетесь FAR, вам понадобятся отдельные программы. Все программы, перечисленные ниже, бесплатны.

Утилиты от Microsoft

Windows >= Vista

В Windows Vista добавили команду

mklink

для создания символьных и жёстких ссылок.

Windows >= 2000
fsutil hardlink create ссылка файл

Создаёт Hard Link на файл (источник).

linkd ссылка директория

Создаёт Junction Point на директорию (источник). Утилита входит в Microsoft Windows Resources Kit.

Расширения для Explorer

NTFS Link интегрируется в Explorer и добавляет во всплывающее меню, появляюшееся после перетаскивания правой кнопкой мыши, пункты «Create junction point» и «Create hard link». Кроме того, она перехватывает вызовы Explorer’а, обеспечивая нормальное перемещение/копирование/удаление созданных ссылок.

NTFS Links (не путать с дополнением для Total Commander) — абсолютно аналогичная программа.

Я рекомендую: Link Shell Extension — аналогичная программа, обладающая расширенным функционалом и очень подробным описанием.

NTFS Links — дополнение для Total Commander

Страница программы. Плагин может запускаться как отдельная программа, вне Total Commander’а.

FAR

Консольный файловый менеджер FAR уже давно поддерживает Hard Links и Junction Points «из коробки». Для создания ссылки используйте сочетание клавиш Alt-F6.

Junction Link Magic

Junction Link Magic — программа с графическим интерфейсом для создания, изменения и модификации Junction Points.

Junction — консольная программа для создания Junction Points

Junction лучше, чем

linkd

, тем, что не нужно тащить весь Resource Kit.

Источник