rpm -qa | egrep "(xinetd|vsftpd)" xinetd-2.3.14-alt2 vsftpd-2.0.5-alt3 Права на директорию /var/ftp: ls -la /var/ | grep ftp drwxr-xr-x 10 root ftpadmin 120 Май 14 08:54 ftp Для закачки пользователям anonymous выделена директория "upload": ls -la /var/ftp/ | grep upload drwxrwsr-t 10 ftp ftpadmin 4096 Май 14 08:55 upload Как видно, владельцем директории является пользователь ftp со всеми необходимыми правами, но закачать в эту директорию анонимам не получается т.к. vsftpd не подменяет пользователя на ftp, а пытается закачивать файлы/папки от имени пользователя vsftpd никак не реагируя на опции в конфиге: chown_uploads=YES chown_username=ftp. Как бы поправить эту ситуацию?
Собственно ошибки тут вроде как и нет и вопрос следовало бы задать в sysadmins@. vsftpd для модификации объектов fs использует либо значение nopriv_user (если выполнен анонимный вход), либо делает это от имени конкретного аутентифицировавшегося юзера. А параметры chown_uploads=YES chown_username=ftp будут применены уже _после_ закачки файла.
хм... очень сомневаюсь в этом по двум причинам: 1) при смене прав chmod 3777 /var/ftp/upload закачка рвётся с сообщением о получении некорректного значения с сервера (Неверный ответ 'n' полученный от сервера.), но файл создаётся нулевого размера у которого владелец указан именно vsftpd. Если создавать директорию, то всё создается без ошибок, но по прежнему владелец vsftpd (так что вы там говорите о смене пользователя после закачки?), при смене владельца (chown -R vsfpd /var/ftp/upload) на vsftpd получаем вот что: May 20 04:10:37 gate xinetd[31669]: libwrap refused connection to ftp (libwrap=vsftpd) from 213.210.105.5 2) vsftpd запускается суперпользователем и имея все права (777) можно чего нибудь придумать в плане безопасности, а по простому - не безопасно! P.S. этот-же конфиг (только настроенный как демон listen=YES) + самосборный vsftpd абсолютно нормально работает на томже сервере с абсолютно темиже правами, а вот родной альтовский нет :( Парадокс. Именно поэтому и пишу сюда а не в sysadmins т.к. посчитал это багой. P.S.S. если у Вас всё корректно работает - поделитесь опытом, буду признателен.
Упс, насчёт nopriv_user я попутал. > May 20 04:10:37 gate xinetd[31669]: libwrap refused connection to ftp > (libwrap=vsftpd) from 213.210.105.5 only_from в xinetd? Вот так всё работает: # grep ^[^#] /etc/vsftpd.conf anonymous_enable=YES anon_upload_enable=YES local_enable=YES write_enable=YES local_umask=002 anon_umask=002 anon_upload_enable=YES dirmessage_enable=YES xferlog_enable=YES connect_from_port_20=YES chown_uploads=YES chown_username=vsftpd chroot_local_user=YES # pwd /var/ftp/upload # ls -ld . drwxrws--- 2 vsftpd vsftpd 80 May 21 10:22 .
Про то, что с пользователем и тем более группой владельцем - vsftpd работает я и не отрицал, но вопрос был совсем не о том. Вопрос был в том почему не работает если я указываю владельцем пользователя ftp или любого другого и при этом права у этого владельца на соответствующую директорию (каталог) - upload имеются в полном объёме. Предлагаемый Вами способ (смена владельца на vsftpd директории upload) будет работать, но в этом случае не вижу смысла в этих двух строчках Вашего конфига: chown_uploads=YES chown_username=vsftpd т.к.с такой политикой - drwxrws--- 2 vsftpd vsftpd 80 May 21 10:22 всем что ни зальёт аноним и без того будет владеть пользователь и группа vsftpd. Поэтому правильней будет эти строчки Вам вообще убрать из конфига! Так что пока вопрос открыт...
(In reply to comment #4) > Про то, что с пользователем и тем более группой владельцем - vsftpd работает я > и > не отрицал, но вопрос был совсем не о том. > Вопрос был в том почему не работает если я указываю владельцем пользователя > ftp а с какой стати vsftpd будет делать setuid ftp? > Предлагаемый Вами способ (смена владельца на vsftpd директории upload) будет > работать, но в этом случае не вижу смысла в этих двух строчках Вашего конфига: > chown_uploads=YES > chown_username=vsftpd У меня тут обычно стоит не vsftpd, для того чтобы ананимусы могли только заливать но не удалять залитое. Ксати права на upload тогда лучше поставить 3770 root:vsftpd
> а с какой стати vsftpd будет делать setuid ftp? хм... например с такой: chown_uploads=YES chown_username=ftp > > > Предлагаемый Вами способ (смена владельца на vsftpd директории upload) будет > > работать, но в этом случае не вижу смысла в этих двух строчках Вашего конфига: > > chown_uploads=YES > > chown_username=vsftpd > > У меня тут обычно стоит не vsftpd, для того чтобы ананимусы могли только > заливать но не удалять залитое. Это к делу не относиться. Всё зависит от значения опции - anon_other_write_enable=YES у меня она как видите в YES. > > Ксати права на upload тогда лучше поставить 3770 root:vsftpd Я бы даже сказал 3774 иначе у меня пользователи просто не увидят того чего они записали. У меня пока не решу окончательно эту проблему сейчас сделано так: chmod 3774 /var/ftp/upload тоесть: drwxrwsr-T 8 vsftpd ftpadmin 4096 Май 30 15:40 upload И полностью убрал из конфига строки: chown_uploads=YES chown_username=ftp но это не айс...
(In reply to comment #6) > > а с какой стати vsftpd будет делать setuid ftp? > > хм... > например с такой: > chown_uploads=YES > chown_username=ftp man 5 vsftpd.conf /chown_uploads
Как-то я неправильно изъясняюсь видимо... или вообще не умею этого делать, но у меня такое впечатление, что у нас с Вами разговор как у слепого с немым. Если я где-то не прав так вы подскажите более понятным образом, пока я вообще не вижу сдвигов, man vsftpd.conf я уже читал достаточно подробно + ознакомился как это сделано у других и не вижу ошибок с моей стороны. chown_uploads If enabled, all anonymously uploaded files will have the ownership changed to the user specified in the setting chown_username. This is useful from an administrative, and perhaps security, standpoint. Если включено, то всем анонимно загруженным файлам изменяется право владения на пользователя, определенного в настройке chown_username. Это полезно с точки зрения безопасности и для администрирования. И что нового я познал? Ещё раз повторяю, что мне именно в целях безопасности и именно более удобного администрирования нужно чтобы всё это также адекватно работало (т.е. была возможность загружать файлы) при замене не на vsftpd пользователя, а на простого ftp да и вообще любого другого. Как это работает в других дистрибутивах. При этом заметил ещё странную вещь - если не убрать из конфига: chown_uploads=YES chown_username=vsftpd то файлы закаченные в upload имеют права 600 хотя в /etc/vsftpd/conf есть запись file_open_mode=0777, если закоментировать всё что связано с chown, то всё встаёт на свои места т.е. файлы имеют нужные права, вот уж чертовщина... P.S. file_open_mode The permissions with which uploaded files are created. Umasks are applied on top of this value. You may wish to change to 0777 if you want uploaded files to be executable. Default: 0666
(In reply to comment #8) > chown_uploads > Если включено, то всем анонимно загруженным файлам изменяется право владения на > пользователя, определенного в настройке chown_username. и где тут написано, что vsftpd делает setuid в этого пользователя? > И что нового я познал? Ещё раз повторяю, что мне именно в целях безопасности и > именно более удобного администрирования нужно чтобы всё это также адекватно > работало (т.е. была возможность загружать файлы) при замене не на vsftpd > пользователя, а на простого ftp да и вообще любого другого. Как это работает в > других дистрибутивах. А может в "других дистрибутивах" vsftpd работает как раз от юзера ftp? > При этом заметил ещё странную вещь - если не убрать из конфига: > chown_uploads=YES > chown_username=vsftpd > то файлы закаченные в upload имеют права 600 man 5 vsftpd.conf /anon_umask P.S. я заканчиваю сюда писать, т.к. это не багрепорт а обсуждение "как мне настроить vsftpd" :(
(In reply to comment #9) > А может в "других дистрибутивах" vsftpd работает как раз от юзера ftp? > Не уверен. В Debian-е и FreeBSD у меня проблем не возникло, а вот с Альтом что-то не срослось... > > При этом заметил ещё странную вещь - если не убрать из конфига: > > chown_uploads=YES > > chown_username=vsftpd > > то файлы закаченные в upload имеют права 600 > > man 5 vsftpd.conf > /anon_umask Хорошая шутка - смешно :) Маска у меня 022. Печально, но похоже придётся оставаться на самосборном vsftpd :(
У меня vsftpd работает таким образом, как вы спрашиваете, с помощью # grep '^[^#]' /etc/vsftpd.conf anonymous_enable=YES write_enable=YES anon_upload_enable=YES chown_uploads=YES chown_username=ftp Убедитесь в том, что у вас свежий vsftpd и актуальный конфиг.
Ок. Обновился имеем: rpm -qa | egrep "(xinetd|vsftpd)" docs-vsftpd-0.1-alt2 xinetd-2.3.14-alt2 vsftpd-2.0.6-alt1 Чтобы небыло разночтений для теста сделал так как Вы мне предложили + добавил три строчки в конце (ничего крименального). Итак: Настройки: [root@bv ~]#cat /etc/xinetd.d/vsftpd # default: off # description: The vsftpd FTP server. service ftp { disable = no socket_type = stream protocol = tcp wait = no user = root nice = 10 rlimit_as = 64M server = /usr/sbin/vsftpd # server_args = } [root@bv ~]# cat /etc/xinetd.conf # # Simple configuration file for xinetd # # Some defaults, and include /etc/xinetd.d/ defaults { log_type = SYSLOG authpriv info log_on_success = PID HOST DURATION log_on_failure = HOST instances = 100 per_source = 5 # only_from = 127.0.0.1 } includedir /etc/xinetd.d [root@bv ~]# cat /etc/vsftpd.conf anonymous_enable=YES write_enable=YES anon_upload_enable=YES chown_uploads=YES chown_username=ftp anon_root=/home/ftp anon_umask=022 file_open_mode=0777 Права на директорию: [root@bv ~]# ls -la /home/ftp/incoming итого 0 drwxrwsrwt 2 ftp ftpadmin 27 Июн 2 16:22 . drwxr-xr-x 5 root root 39 Июн 2 16:22 .. -rw------- 1 vsftpd ftpadmin 0 Июн 2 16:22 vsftpd.tar.bz2 Здесь видно что vsftpd.tar.bz2 имеет нулевой размер — это в результате копирования в эту директорию при владельце ftp. При этом в логе закачиваемого клиента (gFTP), а при закачке клиент очень долго думал, он с сервера не выкидывало: USER anonymous@192.168.1.10:0 331 Please specify the password. PASS xxxx 230 Login successful. SYST 215 UNIX Type: L8 TYPE I 200 Switching to Binary mode. CWD /incoming 250 Directory successfully changed. PORT 192,168,1,10,134,173 200 PORT command successful. Consider using PASV. STOR /incoming/vsftpd.tar.bz2 553 Could not create file. Загрузка списка файлов каталога /incoming с сервера (LC_TIME=ru_RU.UTF-8) PORT 192,168,1,10,174,243 200 PORT command successful. Consider using PASV. LIST -aL 150 Here comes the directory listing. 226 Directory send OK. Ok. Удаляем закачаный нулевой файл и меняем владельца на vsftpd. [root@bv ~]# rm -f /home/ftp/incoming/vsftpd.tar.bz2 [root@bv ~]# chown vsftpd /home/ftp/incoming Пробуем закачать: USER anonymous@192.168.1.10:0 331 Please specify the password. PASS xxxx 230 Login successful. SYST 215 UNIX Type: L8 TYPE I 200 Switching to Binary mode. PWD 257 "/" Загрузка списка файлов каталога / с сервера (LC_TIME=ru_RU.UTF-8) PASV 227 (192,168,1,222,9,181) LIST -aL 150 Here comes the directory listing. 226 Directory send OK. CWD /incoming 250 Directory successfully changed. PWD 257 "/incoming" Загрузка списка файлов каталога /incoming с сервера (LC_TIME=ru_RU.UTF-8) PASV 227 (192,168,1,222,9,183) LIST -aL 150 Here comes the directory listing. 226 Directory send OK. Локальный каталог успешно изменён на /home/bv/VSFTPD Загрузка списка файлов каталога /incoming из кэша (LC_TIME=ru_RU.UTF-8) PASV 227 (192,168,1,222,9,216) STOR /incoming/vsftpd.tar.bz2 Загрузка списка файлов каталога /incoming с сервера (LC_TIME=ru_RU.UTF-8) PASV PORT 192,168,1,10,206,79 Неверный ответ 'n' полученный от сервера. Отключение от сервера 192.168.1.10 При этом файл залился тоже нулевого размера, но при этом выкинуло с сервера. [root@bv ftp]# ls -la /home/ftp/incoming/ итого 0 drwxrwsrwt 2 vsftpd ftpadmin 27 Июн 2 16:45 . drwxr-xr-x 5 root root 39 Июн 2 16:22 .. -rw------- 1 vsftpd ftpadmin 0 Июн 2 16:45 vsftpd.tar.bz2 Ладно... Меняем в конфигурационном файле vsftpd при этом не меняем владельца директории, т.е. оставляем chown vsftpd incoming: chown_username=vsftpd Теперь заходим заново на сервер (предварительно также вычистив эту директорию) и пробуем залить тот-же файл: [root@bv ftp]# ls -la /home/ftp/incoming/ итого 24 drwxrwsrwt 2 vsftpd ftpadmin 27 Июн 2 16:51 . drwxr-xr-x 5 root root 39 Июн 2 16:22 .. -rw------- 1 vsftpd ftpadmin 23722 Июн 2 16:51 vsftpd.tar.bz2 И всё прекрасно залилось. Продолжаем... Убираем такие строки из конфига вообще: chown_uploads=YES chown_username=vsftpd Получаем: [root@bv incoming]# ls -la /home/ftp/incoming/ итого 24 drwxrwsrwt 2 vsftpd ftpadmin 27 Июн 2 16:59 . drwxr-xr-x 5 root root 39 Июн 2 16:22 .. -rwxr-xr-x 1 vsftpd ftpadmin 23722 Июн 2 16:59 vsftpd.tar.bz2 Всё залилось, он вот с подменой владельца ну никак....
(In reply to comment #12) > Чтобы небыло разночтений для теста сделал так как Вы мне предложили В моём тесте владельцем каталога upload был root.
(In reply to comment #13) > (In reply to comment #12) > > Чтобы небыло разночтений для теста сделал так как Вы мне предложили > > В моём тесте владельцем каталога upload был root. > Это дело не меняет! [root@bv ftp]# ls -la /home/ftp/incoming итого 0 drwxrwsrwt 2 root ftpadmin 27 Июн 3 08:15 . drwxr-xr-x 5 root root 39 Июн 2 16:22 .. -rw------- 1 vsftpd ftpadmin 0 Июн 3 08:15 vsftpd.tar.bz2 Как мы видим якобы залитый (нулевого размера) файл с владельцем vsftpd но никак не ftp. В случае с наследованием GID и закрепляющего бита на директорию ftp-клиент отваливается с ошибкой: Неверный ответ 'n' полученный от сервера. Отключение от сервера 192.168.1.10 При отключении наследования (т.е. chmod 0777 /home/ftp/incoming) отваливается по таймауту и видим всё также нулевой файл: STOR /incoming/vsftpd.tar.bz2 Тайм-аут соединения 192.168.1.10 Отключение от сервера 192.168.1.10 Ошибка: Удалённый сервер отключился после попытки передать файл Невозможно выкачать /home/bv/VSFTPD/vsftpd.tar.bz2 c локальная файловая система Ошибка: Удалённый сервер локальная файловая система отключился. Повторное соединение будет выполнено через 30 секунд. И вы хотите сказать, что баги нет?
(In reply to comment #14) > И вы хотите сказать, что баги нет? Я хочу сказать, что я не смог её воспроизвести. Наиболее вероятно, что у вас какая-то локальная специфика.
(In reply to comment #15) > (In reply to comment #14) > > И вы хотите сказать, что баги нет? > > Я хочу сказать, что я не смог её воспроизвести. > Наиболее вероятно, что у вас какая-то локальная специфика. Странно конечно. У меня одинаково не работает vsftpd на двух машинах. На одной у меня серверная версия + обновлён из ветки branch (собственно на неё я и хотел всё "правильно" настроить), а на второй - это та на которой работаю, но всё бестолку :( Ну ладно, буду как-то пытаться решить сложившуюся ситуацию. Спасибо всем за терпение и помощь.
