LINUX.ORG.RU

[ftp,sftp,etc?] Удаленный доступ к файлам, виртуальные юзеры, виртуальные права


0

0

Делаю системку управления документами. Нужна возможность загружать файлы документов через фтп (или какнить ещё). Но не желательно раздавать системные аккаунты юзерам программы да и логику доступа к документам в программе к системе контроля прав на файлы в линуксе будет очень-очень трудно привязать.

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

Если кто сталкивался с такой проблемой, подскажите плз.

anonymous

pure-ftp

он имеет виртуальных пользователей: список либо в passwd-like файле, либо в БД. и вообще, он просто рулит ;)

Pi ★★★★★
()

Сдаётся мне, что с ProFTPD так сделать не выйдет, а значит не выйдет и с другими ftp-серверами. Значит надо писать например CGI-скриптик, который по имени файла будет смотреть, имеет ли юзер право его читать, а потом уже отдавать этот файл. А прямого доступа к файлам не давать, только через этот скрипт.

Тема на для Development IMHO.

Teak ★★★★★
()
Ответ на: комментарий от Teak

>и логику доступа к документам в программе к системе контроля прав на файлы в линуксе будет очень-очень трудно привязать.

ойой, не углядел... с фтп такое наверное не получится сделать... :(

Pi ★★★★★
()
Ответ на: комментарий от Pi

Да-да. Я за это время успел просмотреть доку pure-ftp и как раз хотел написать, что ты гонишь. :)

Teak ★★★★★
()
Ответ на: комментарий от Pi

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

Pi ★★★★★
()
Ответ на: комментарий от Pi

Ужос. :)

А выйти по линке из домашней директории ему дадут? Если дадут, то у меня вызывает опасения секурность данной схемы. :)

Лучше скриптом отдавать по HTTP, просто и ясно.

Teak ★★★★★
()
Ответ на: комментарий от Teak

>А выйти по линке из домашней директории ему дадут?

ну а почем эт дадут?.. линк указывает просто на файл (за всё отвечает ФС), вот если на директорию, тогда да: она будет листится.

>Лучше скриптом отдавать по HTTP, просто и ясно.

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

Pi ★★★★★
()
Ответ на: комментарий от Pi

Не, тема с хттп не пойдет

Доступ через вебморду ужо есть, но проблема в том что бы чел мог сразу кучу файлов закинуть (через фтп или ещё как нить) и не смог бы пофиксить файлы в других папках-документах. А логика прав доступа в программе оч. сложная.

Я так понимаю что простых решений нет и придецца доделывать какой нибудь фтп сервер...

anonymous
()
Ответ на: комментарий от Pi

> линк указывает просто на файл (за всё отвечает ФС), вот если на директорию, тогда да: она будет листится

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

С уважением -- Смоляное Чучелко

anonymous
()
Ответ на: Не, тема с хттп не пойдет от anonymous

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

Какой проблем? POST-запрос со скриптом на том стороне...

С уважением -- Смоляное Чучелко

anonymous
()
Ответ на: комментарий от anonymous

Вы не понимаете

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

anonymous
()

>но что бы все пользователи и права на файлы определялись бы ... в программе

Зачем изобретать велосипед? Такая программа _уже_ _есть_, притом довольно хорошо отлаженая и по возможности обезбаженая, называется "linux"(который ядро).

DonkeyHot ★★★★★
()
Ответ на: комментарий от Pi

Возможный солюшн

Net::FTPServer http://search.cpan.org/~rwmj/Net-FTPServer-1.122/lib/Net/FTPServer.pm

по крайней мере у них заявлено "Virtual filesystem allows files to be served from a database."

Ничего другого не нашел. Ну ничо, покатит и перл. Думаю, на 40 юзерах не загнется и то ладно. А так с шефом поговорил, наверное осенью возьмем сишника и форкнем какой нить опсос фтп ))) Например pure-ftpd.

Добавим туда поддержку vfs+sql

anonymous
()

tcl - наше фсё :)
для сетевой части берётся ftpd,smtpd,pop3d,httpd,TclSOAP
для собствеено документов doctools
 
на них прикручивается всё что душе угодно..самодельная авторизация с одноразовыми паролями, sql-fs, etc..

MKuznetsov ★★★★★
()

> логику доступа к документам в программе к системе контроля прав на файлы в линуксе будет очень-очень трудно привязать.

а если заюзать acl, то тоже никак?

scotinomys
()

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

я вам сейчас одну страшную вещь скажу:

> Zope FTP is clever. You don't FTP to the file system on the Zope server, but directly to Zope. The file and folder that the FTP client "sees" are Zope objects in the ZODB. So when you for instance create an article and transfer it to Zope via FTP, all the metadata, templating and workflow stuff is handled properly.

http://zope.org/Members/stonor/ftp

оно делает как раз то что надо, но если опыта нет -- может оказаться неподъёмно

scotinomys
()
Ответ на: комментарий от Pi

>а если система распределённая и людям нужен single sign on

У меня sizeof(uid_t) == 4, до 2х с лишним миллиардов пользователей этого хватит. Конечно, китайскому правительству будет о чём задуматься, при условии 150%-ной компютеризации населения. Остальным - выше крыши.

SSO и распределённость этому ортогональны.

DonkeyHot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.