Dotaz: openssh - chrooted sftp subsytem a permissions

[ET]

Zdravim,

neresil tu nahodou nekdo, jak lze nastavit opravneni pro vsechny nahravane soubory pres sftp subsystem (internal-sftp) openssh?

Zkousel jsem "latest" verzi openssh 5.9p1 a v man se pise, ze pri pouziti parametru -u pro subsystem sftp lze nastavit umask pro nahravane soubory - bohuzel toto v chrootu nefunguje podle mych predstav (resp. funguje, ale nahravane soubory musi mit "vyssi" opravneni nez nastavuje sftp umaska parametrem "-u" - tj. nahravam-li soubor s pravy pouze pro cteni(444), umaska se neprojevi a nahrany soubor je taky 444; pokud nahravam soubor s full pravy(777) pak se maska korektne uplatni. Predpokladat, ze uzivatel pred uploadem nastavi "korektni" prava je cesta do pekel, proto to neberu jako reseni problemu)

Odpovědi

[NN]

Jakou mas nakonfigurovanou masku u parametru -u?

NN

[Sten]

umask je maska, takže ta to nevyřeší. Něco zvládne ACL, i když to taky není úplně blbuvzdorné. Asi nejlepší řešení je nastavovat to přes inotify.

[Šangala]

Pokud je to třeba in-time, tak inotify, ale pokud s nějakým zpožděním, tak cron (třeba po 10min), ale! přes find najít jen ty, co mají neodpovídající práva a ty změnit, něco jako find cesta -type f ! -perm 664 -exec chmod 664 {} \; - má to „realativně“ nízkou režii a nezacyklí se to ani nad větším filesystémem pokud se to nebude pouště po 5sec (u rozsáhlého filesystému je třeba myslet na to, že i ten find musí zjistit informace o každém souboru).

[ET]

Cau,

jelikoz ty nahrany soubory pak zpracovava php, tak jsem to nakonec "vyresil" prevlastnovanim pres sudo z php

@NN - Potreboval jsem pridat prava pro skupinu (0775) takze umask jsem pouzil 0002, ale chovalo se to jak jsem popisoval vyse (coz je asi korektni chovani)

@Sangala - Puvodne/docasne jsem to resil tim findem, ale jelikoz ty soubory pak zpracovava php (v me nezname dobe), tak nemuzu spolehat na to, ze v dobe zpracovani php skriptem budou vsechny soubory prevlastneny (samozrejme moje chyba, ze jsem to nenapsal do dotazu); dalsi vec co me vadi je, ze to pousti cron i kdyz to neni potreba (nejsou zadne nove soubory)

@inotify - na produkcni server se mi to nechce nasazovat jen kvuli tomuhle problemu (resp. az jako posledni moznost)

jeste me napadlo natvrdo "zadratovat" prava do zdrojaku od openssh, bohuzel nemam tak dobrej skill v C tak pokud by se nasla dobra duse a pomohla najit misto kde to zmenit, tak bych to ocenil :]

jinak dekuju za cenne rady

[pavlix]

@inotify - na produkcni server se mi to nechce nasazovat jen kvuli tomuhle problemu (resp. az jako posledni moznost)

He?

[ET]

osobni zkusenost s inotify nemam, ale vetsina navodu zacina instalaci inotify-tools

(drzim se pravidla, ze co na server nemusi byt, to tam neni)

[pavlix]

Je mi líto, ale tomuhle přístupu se nemůžu než smát. Ale aspoň máš život jednodušší, když ti stačí řídit se sadou pravidel a nepotřebuješ moc používat mozek.

Osobně mám totiž podezření, že celý problém, který tady v poradně řešíš, si ve skutečnosti sám způsobuješ nějakou dřívější chybou. Tedy řešíš důsledek místo příčiny.

Kdybych si měl vybrat, jestli budu instalovat horkou jehlou upravenou klíčovou část systému nebo doinstalovat standardní nástroj, určitě bych jako argument nepouži, že daný není ještě nainstalován.

[ET]

jasny, smej se, podobnou odpoved jsem bohuzel cekal... (nenarazim na tvou osobu, ale na diskuze zde na abc - tazatel je mnohokrat oznacen za blbce a nic nejde a kdybych JA mohl, tak to udelam nejlip, chjo... )

fyi: ja jsem jen "admin" a ve vetsine pripadu se me nikdo nepta, jak to/ono implementovat, ale jen jak preskocit nejakou prekazku na ceste k cili - v tomto pripade byl pozadavek sftp takze bych to stejne resil (kdybych to vymyslel)...

podle me je nejlepsi resit zmenu prav a] bud hned pri nahravani souboru (muj dotaz ohledne ossh), nebo pred zpracovanim (moje "semi" reseni se sudem) - vse ostatni je zbytecnej overhead a ten na serverech nepotrebuju

zdar

[pavlix]

jasny, smej se, podobnou odpoved jsem bohuzel cekal... (nenarazim na tvou osobu, ale na diskuze zde na abc - tazatel je mnohokrat oznacen za blbce a nic nejde a kdybych JA mohl, tak to udelam nejlip, chjo... )

Neříkám, že jsi blbec. Jsi pouze pomýlený v této konkrétní oblasti. Přijde mi fér ti to říct takto naplno, alespoň máš o něco málo větší šanci si to uvědomit. Samozřejmě tě nikdo nenutí tuto šanci využít.

[Sten]

inotify je subsystém jádra. Ty inotify-tools jen umožňují jej jednoduše používat ze shellu. Takže i když jste inotify nikdy nepoužil, tak jej tam stejně máte a pravděpodobně tam máte i aplikace, které jej používají.

[pavlix]

+1

[Šangala]

inotify - je na tyto „problémy“.
find & naprázdno - na rozumném počtu souborů pokud nedošlo k žádné změně od minule proběhne v řádech jednotek milisekund.

[ET]

na rozumném počtu souborů

jenze na tohle spolehat nechci, nehlede na to ze ten server je virtualizovan ve vmware a I/O stoji uz takhle za prd

[Šangala]

Rozumném počtu jsem nemyslel „stovku“, prostě méně než několik stovek tisíc.
PS: Tipl bych si, že zrovna tato operace bude pravděpodobně na virtuální disku rychlejší než na přímém železe.

[ET]

PS: Tipl bych si, že zrovna tato operace bude pravděpodobně na virtuální disku rychlejší než na přímém železe.

zajimavy, z ceho tak usuzujes/te?

[Šangala]

Ze zkušeností na XEN-u a VMWare Workstation.
Pokud nedochází ke změně a disk je „souborový“ a i když nemá daná virt. mašina v cache tyto informace, má pravděpodobně filesystém (či strukturu) v cache virt. engine na hostiteli, takže spousta drobných operací se tak jako tak děje v paměti (pokud je dost prostředků, a změn není mnoho).
Ale myslím, že je to irelevantní, nad 241 417 soubory v adresářové struktuře mi find -xdev -type f ! -perm 664 > /dev/null poprvé trval na běžném železe něco kolem 16sec (je možné že bylo již něco v cache), ale opakovaně po 10min (a to struktura žije) 0.8 - 1.3 sec.