Proftpd jogok - uid, gid

Fórumok

Üdv,

Adott egy klasszikus proftpd+mysql combo, működik.

Az ftp a /var/www/-be dolgozik, ahol az apache wwwrun:www-nal (30:8) fut, ergó ha ez alatt minden ilyen, nincs probléma a jogosultságokkal, mindent tud írni az apache(php). Több domain, több felhasználó, domain kvota, user kvota. Ez akkor működik, ha a mysqlben minden domainnek más a gid-je, minden usernak más a uid-je,gid ugye domainfüggő. Ekkor találja meg a proftpd, ki kivel van. Ezzel az a baj, hogy az sqlben megadott uid/gid-del akarja a fájlokat/direket is létrehozni, el elkezdődik a kuszálódás. Persze, lehetne minden 777, amit a juzer állítgat át ftp-n, ha az oldala írni akar oda... Ezt a rengeteg uid/gid-et akarom elkerülni: legyen minden wwwrun:www. De sajnos nem találtam módját annak, hogy az sql adatokat felülírjam fájlrendszer szinten. Tud valamelyikőtök erre megoldást?

Köszönöm.

Hozzászólások

teljesen nonszensz, hogy minden egy bizonyos uid:gid, a proftpd nyilvan egy adott uid:gid parossal fut, de adoss user-homedie-passowrd paroshoz egy teljesen mas uid:gid tartozik, tartozzon.

t

Proftpd ha pl. ftpuser-rel fut, elér mineden www domain mappát (apache is ftpuser nevvel fut). A proftpd mysql-ében létrehozott userek _virtualuserek_, igy ha az uid/gid mindenkinek egy fix az sql-ben (ftpuser UID), mindeki elérheti a sajátját, és user szinen raksz quotát. Ez nem megoldás?
Nálam igy működik gond nélkül.
Egy dologba lehet belekötni...mindenki egy néven fut és csak a chroot jelleg véd proftpd-ben illetve az openbasedir php esetében.

--
Desktop: 2.6.21-gentoo-r4 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
Laptop: 2.6.22-gentoo-r5 Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz

igen, most ez van. mysqlből az ftp wwwrun:www -vel hoz létre fájlt könyvtárat.
azt nem tudom, hogy csak userkvotaval menne-e, de ugye jó lenne tudni a következőt a rendszernek:
domain kvota: adott tárhelyre max 100Mb-ot tolhat fel pl.
user kvota: a domainhez kioszthatsz usereket, és azoknak is lehet egyenként kvotazni. lesz pl aki csak 10MBot tölthet fel, vagy egyáltalán nem lesz kvotaja az ftp accnak, de a 100MBot így sem lépheti tul, mivel a group kvota erősebb.

mert lehetne, hogy mindent 777es maskkal hozatok létre, mysqles uid-gid-del, de akkor sok lesz a felesleges gid/uid, és akkor minden írhat mindent. valahogy felül kéne bírálni az mysql gid-eket...

ezek futnak le loginnél:

S ELECT userid, passwd, uid, gid, homedir, shell FROM ftp_users WHERE (userid='user@domain.hu') AND ((active='1')) LIMIT 1
meglesz az uid/gid(8), majd:
S ELECT groupname FROM ftp_group WHERE (gid = 8) LIMIT 1
ezzel ami előbb lesz a sorban, ahhoz fogja csapni, domainhez ugye nem lehet kötni, mert akármi usernevet adhatok, domain nélkül.
innentől a kiválaszott domainhez fog tartozni....

2 észrevétel és csak elméletben:
- ha az ftp és az Apache egy azon userrel fut, akkor elvileg bárki könnyűszerrel írhatja az összes könyvtárat.
- ha a quota csak user szinten a mysql-ben van beállítva, akkor elvileg az apacheon keresztül korlátlanul lehet foglalni a helyet tovább, pl. fájlfeltöltéssel.

jo lenne tudni, hogy proftpd csak loginhoz hasznalja az adott uid, guid parost, vagy a kvotat is ez alapjan szamolja.
mert ha csak loginadat, akkor lehetne hookolni proftpd-t, hogy minden fajlfeltoltes/modositas utan chown-olja at a feltoltott/modositott fajlt www-data tulajdonaba.
de ha ez alapjan szamolja a kvotahoz a jelenleg foglalt helyet, akkor ez megintcsak megboritana.
a masik megoldas az lenne, hogy mindenkinek(minden virtualhostnak) a sajat neveben futna az apache (fastcgi + suexec), es igy ugyanazzal a felhasznaloval mehetne az adott virtualhost, mint amivel ftp userkedik.

szerk: ha a proftpd az uid/gid alapjan szamolja az user/domain kvotat, akkor azt at lehetne irni, hogy egyszeruen csak 1 domain kvota legyen, tehat ha az ftp homedirban levo fajlok altal foglalt teljes meret nagyobb egyenlo kvota akkor ne engedjen feltolteni ujabbat.
http://www.castaglia.org/proftpd/doc/devel-guide/internals/events.html

Tyrael

mennyire elvetemult otlet a mod_exec+chown az uploadok utan? :S

bocsánat, hogy közbeszólok, de ez sztem defective by design. userként kéne kezelni a usereket, a biztonságra pedig jobban odafigyelni (suexec, suphp, fcgi, stb..)