Проблема безопасности: nginx (+ISPManager, как частный случай)

Вообще то ситуация была иная

На контроллере стоит старая прошивка, которая портит данные

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

Разумеется ты ее не сможешь решить, так как тебе помешает фанатизм

Это тоже не ситуация, а "андрейка". Практических решений у данной гипотетической "ситуации" - масса. Включающих и "смени контроллер", и "собери свое ядро" и еще десяток вариаций.

Контроллер меняют слабаки

И что - каждый раз будешь ручками ядро пересобирать? Офигенная автоматизация с этим вашим дебьяном получается!

вот еще попалось по теме.

и еще

Что-то не видать O_NOFOLLOW_IF_OWNER_NOT_MATCH в man 2 open, и вообще никак не гуглится этот флаг.

---------- Добавлено в 22:39 ---------- Предыдущее сообщение было в 22:27 ----------

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

$ find  -ls
 32974    4 drwxr-xr-x   4 ab       ab           4096 Jan  8 02:27 .
2777674    8 -rwxr-xr-x   1 ab       ab           6909 Jan  8 02:24 ./a.out
665616    4 drwxr-xr-x   3 ab       ab           4096 Jan  8 02:15 ./a
665617    4 drwxr-xr-x   2 ab       ab           4096 Jan  8 02:15 ./a/b
2056928    4 -rw-r--r--   1 ab       ab              2 Jan  8 02:15 ./a/b/c
665618    4 drwxr-xr-x   2 ab       ab           4096 Jan  8 02:26 ./d
2114220    0 lrwxrwxrwx   1 ab       ab              8 Jan  8 02:33 ./d/e -> ../a/b/c
2114219    0 lrwxrwxrwx   1 ab       ab              6 Jan  8 02:26 ./d/f -> ../a/b
2777675    4 -rw-r--r--   1 ab       ab            268 Jan  8 02:24 ./NoGo.c
$ cat NoGo.c 
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#define  __USE_GNU
#include <fcntl.h>

int
main(int argc, char* argv[])
{
  int f = open(argv[1],O_NOFOLLOW|O_RDONLY);
  int n;
  char l[80];

  while((n=read(f,l,80))>0)
    write(1,l,n);

  return 0;
}
$ cc NoGo.c
$ echo "Фиговый листик" > a/b/c
$ ./a.out d/f/c # Упс :)
Фиговый листик
$ ./a.out d/e # а вот так работаит :)
$ 

$ find  -ls

 32974    4 drwxr-xr-x   4 ab       ab           4096 Jan  8 02:27 .

2777674    8 -rwxr-xr-x   1 ab       ab           6909 Jan  8 02:24 ./a.out

665616    4 drwxr-xr-x   3 ab       ab           4096 Jan  8 02:15 ./a

665617    4 drwxr-xr-x   2 ab       ab           4096 Jan  8 02:15 ./a/b

2056928    4 -rw-r--r--   1 ab       ab              2 Jan  8 02:15 ./a/b/c

665618    4 drwxr-xr-x   2 ab       ab           4096 Jan  8 02:26 ./d

2114220    0 lrwxrwxrwx   1 ab       ab              8 Jan  8 02:33 ./d/e -> ../a/b/c

2114219    0 lrwxrwxrwx   1 ab       ab              6 Jan  8 02:26 ./d/f -> ../a/b

2777675    4 -rw-r--r--   1 ab       ab            268 Jan  8 02:24 ./NoGo.c

$ cat NoGo.c 

#include <stdio.h>

#include <sys/types.h>

#include <sys/stat.h>

#define  __USE_GNU

#include <fcntl.h>



int

main(int argc, char* argv[])

{

  int f = open(argv[1],O_NOFOLLOW|O_RDONLY);

  int n;

  char l[80];



  while((n=read(f,l,80))>0)

    write(1,l,n);



  return 0;

}

$ cc NoGo.c

$ echo "Фиговый листик" > a/b/c

$ ./a.out d/f/c # Упс :)

Фиговый листик

$ ./a.out d/e # а вот так работаит :)

$ 

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

Вроде как не сильно зависит: Symbolic links in earlier components of the pathname will still be followed. (c) man 2 open.

---------- Добавлено в 14:01 ---------- Предыдущее сообщение было в 13:55 ----------

Ну про изменение лицензии я знаю -- последняя версия под старой лицензией всё равно будет иметь силу, а про выкидывание пакета не знал. Я с debian всё равно не работаю, но Вы можете собрать пакеты, основанные на оригинальных, и выложить их :)

Там возникает другая проблема. Залил клиент файл с фотками с отпуска на 500 метров и дал своим друзьям ссылку. Они вставили его в менеджер загрузок, который занимается десятипоточным скачиванием. В результате сервер занимается копированием файла из apache в proxy_temp_dir через 127.0.0.1 в кучу потоков.

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

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

По поводу пакетов в дебиан, старые версии не выкидываются, вот хотя бы яву (sun-java6) взять в 30 (емнип) обновлении запретили включать в дистрибутивы, из unstable/testing выкинули, но в stable 28 патч остался.

http://bugs.debian.org/646524

Там приводили другой пример: O_NOLINKS. Как я понимаю - будет работать и против хардлинков.

Для несвободных - наверное может. Но non-free часть репозитория - не является частью debian.

Вполне логично, нет? Пакет никому нафиг не упал, никто им не занимается и не исправляет *важные* проблемы. Нужно такое держать дальше?

Вот в качестве примера, какие пакеты удалялись в недавних релизах:

http://www.debian.org/News/2011/20110625

http://www.debian.org/News/2011/20110122

http://www.debian.org/News/2010/20100904

Она в non-free. Это не дебиан.

Это *может* стать проблемой - но пока только является описанием нормальной работы связки вебсерверов. А почему бы вам, к примеру, не закешировать подобный материал? Это вполне уместно для роли прокси.