catap's blog ~ записки ёmacs'ера

Nginx — это web-сервер который используется многими для отдачи «статики» или как «прокся». Я не исключение. Но я не хочу его хвалить, и так все делают это. Я хочу вам рассказать о проблемах в нем,, которые есть, которые никто не исправляет и мимо которых вы все удачно проходите.

Поверит мне кто‑то или нет, но работа с файлами в nginx сделана опасно. Опасна настолько что файл может просто не открыться именно при обработке одного запроса. Почему? Просто. Вся работа с файлами крутиться вокруг функции:

ngx_int_t ngx_open_cached_file(ngx_open_file_cache_t *cache, ngx_str_t *name, ngx_open_file_info_t *of, ngx_pool_t *pool);

Второй ее аргумент это путь до файла. ngx_str_t это pascal-like string, а если совсем точно:

typedef struct {
    size_t      len;
    u_char     *data;
} ngx_str_t;

data в ней, естественно, без ‘\0’ на конце.

Теперь давайте заглянем в ngx_open_cached_file. Если отбросить работу с кэшем, вся работа сведется к:

rc = ngx_open_and_stat_file(name->data, of, pool->log);

Если не понятно, можно еще посмотреть на эту функцию:

static ngx_int_t ngx_open_and_stat_file(u_char *name, ngx_open_file_info_t *of, ngx_log_t *log)

Как мы тут видим, мы волшебным образом уходим от pascal-like string и приходим к обычным, «сишным», строкам. Чем нам это грозит? Тем что имя файла может оказаться длинее, много длинее чем то, что мы хотим, и нам, скорее всего, скажут что такого файла нет, или мы получим «сегфол».

Если тут все так плохо, то почему это работает так много где и никто не замечает? Очень просто. ngx_open_cached_file используется в 7 местах. И во всех этих местах, так как они сделаны сейчас, это просто безопасно. Т.е. в памяти, за name идут нули. Вот и все. Я не уверен в одном, можно ли утверждать что это будет безопасно всегда, по ощущениям — нет.