| poslední úprava: 18.12.2014 14:40
Portál AbcLinuxu, 2. května 2025 13:45
18.12.2014 14:20
| Přečteno: 2515×
| Za vším hledej Linux
|
| poslední úprava: 18.12.2014 14:40
Před několika dny se ve zdejší linuxové poradně objevil dotaz, který lze přeformulovat zhruba takto: Jak nastavit v konfiguraci Apache WebDAV, aby se přes jedno URL dostal uživatel po přihlášení vždy jen a pouze do svého adresáře? Zaujalo mne to, protože z mého pohledu je WebDAV v současné době snad jediné multiplatformí řešení, vhodné pro sdílení dat, které se obejde bez cloudových služeb velkých společností.
WebDAV je - na rozdíl od protokolů síťových souborových systémů, pouhé rozšíření HTTP protokolu o metody, které umožňují jeho prostřednictvím přenášet po síti soubory také zpět na server. Porty 80 (HTTP) a 443 (HTTPS) jsou na rozdíl od portů, přes které fungují jiné komunikační protokoly, obvykle průchozí, aby se uživatelé mohli z vnitřní sítě dostat na webové stránky. Proto lze přes WebDAV pracovat se soubory i přes relativně striktně nastavený firewall nebo proxy.
Požadavek, aby uživatelé mohli své stránky na serveru rovnou upravovat, byl ostatně také za tím, proč vlastně WebDAV vzniknul. S touto možností se u webu počítalo od samého počátku, jenže od myšlenky byla k funkční implementaci ještě dlouhá cesta. Zatím, co první verze HTTP protokolu s číslem 0.9 byla zveřejněna r. 1991, tak první konkrétní návrh jeho rozšíření o metody s nimiž pracuje současný WebDAV učinil až r. 1996 Jim Whitehead. Do té doby, než byl implementován WebDAV, se nejčastěji upravené soubory uploadovaly na server prostřednictvím FTP klienta.
FTP protokol, určený k síťovému přenášení souborů, je starší než HTTP protokol. Jeho návrh pochází z r. 1986 - z doby, kdy magoři neměli ještě o internetu a možnostech jeho zneužití ani ponětí. Veškerá data se jím přenášela v čitelné podobě - včetně přihlašovacích údajů, takže případnému škůdci stačilo kdekoliv po trase odchytit dostatečné množství paketů a pak v nich tyto údaje vyhledat.
V dřevních dobách webových byl editor webových stránek součástí některých prohlížečů. K přenosu souborů z klientské stanice na server zpočátku používaly pouze FTP jehož specifikace byla r. 1997 rozšířena o přidaní bezpečnostní prvky. Teprve zhruba od r. 2003 se začala objevovat alternativní možnost využít pro upload souborů také WebDAV. Ovšem v té době už měla integrovaný wysiwyg editor pouze Mozilla - poslední verze, která ještě obsahovala editor (1.7.13) byla vydaná na jaře 2008.
Wysiwyg editace HTML stránek byla použitelná pouze pro správu statického webu, ale internetový boom v závěru 20. století vynesl do popředí weby se stránkami s dynamicky generovaným kódem, jejichž finální podoba závisela na renderovacím jádru webového prohlížeče. Pro editaci jejich kódu se víc hodily specializované textové editory, než wysiwyg editory jako byla Amaya, Frontpage nebo editor v Mozille.
Na rozdíl od staršího FTP, nabízel přístup k souborům přes WebDAV jen málokterý webhosting. Většina uživatelů byla zvyklá používat FTP klienta, takže o něj ani nijak zvlášť neměla zájem.
WebDAV se stal zajímavou alternativou až s nástupem chytrých mobilních zařízení s trvalým přístupem s internetové síti. A to pro svůj potenciál využitelný ke sdílení uživatelských dat mezi pracovní stanicí a mobilním telefonem.
HTTP protokol s rozšířením pro WebDAV je ve své podstatě podobně otevřený protokol jako FTP, ale s rostoucími nároky na bezpečnost šla ruku v ruce implementace SSL šifrování na komunikace mezi serverm a klientem, takže v tomto případě nebylo nutné - na rozdíl od FTP - řešit problém se zabezpečením komunikace modifikací specifikace protokolu. Pokud operační systém zařízení umí šifrovat síťovou komunikaci přes SSL, není problém se zabezpečením komunikace klienta pro WebDAV. Takže dnes existují aplikace, které umí integrovat adresáře sdílené přes WebDAV do systému prakticky pro všechny v současné době používané platformy - včetně těch mobilních.
Abychom mohli soubory přes WebDAV sdílet, je třeba mít k dispozici server, který takto rozšířenému HTTP protokolu rozumí. Pokud někomu stačí jednoduchý server, určený pouze ke sdílení souborů, může použít WsgiDAV, ovšem pro řešení zadání, jaké je v perexu tohoto blogpostu je vhodnější použít Apache.
Moje zkušenosti s využitím WebDAVu dosud nebyly nijak velké. Poprvé jsem si s ním hrál zhruba před osmi lety. Viz můj blogpost z r. 2006. Tehdy bylo pro mě podstatné především to, že skrze něj bylo možné protlačit soubory na server ve vnější síti i přes poměrně striktně a navíc idiotsky nastavenou proxy.
Pak ho jeden čas ho využívalo několik našich uživatelů ke vzdálenému přístupu do sdíleného pracovního adresáře. Ale protože stejný server poskytoval zároveň i webové služby, raději jsme od toho ustoupili. Sdílený prostor, dostupný přes WebDAV, který je zároveň publikován přes stejný server jako normální web - byť s autorizovaným přístupem - totiž představuje potencionální problém.
Server přes který publikujeme uživatelské adresáře, si totiž tehdy ještě nevynucoval komunikaci přes SSL, takže hrozila potencionální kompromitace přihlašovacích údajů. Škůdce, který by z odchycené komunikace vypreparoval přihlašovací údaje, mohl uploadovat nenápadný php skript, jehož zavoláním odněkud z webu - bylo možné kdykoliv zaškodit, ne-li rovnou sejmout celý stroj.
WsgiDAV je WebDAV server, napsaný v Pythonu, který podporuje SSL a může komunikovat na libovolném rozhraní a portu. Rovněž umožňuje nakonfigurovat pro každého uživatele samostatný adresář. Pro Debian sice není k dispozici žádný instalační balíček, ale instalace a konfigrace je poměrně triviální.
Narazil jsem na něj dřív než se mi podařilo dojít u Apache k funkční konfiguraci. Nicméně to nebylo řešení, jaké jsem hledal, protože co uživatel, to unikátní URL. Navíc, pokud by server naslouchal na standardním portu 443, tak by již nebylo možné používat normální webový server.
Bylo jasné, že pro dynamické mapování adresářů přes jedno URL je třeba využít Apache, který musí mít kromě modulů mod_dav a mod_davfs zaveden také modul mod_rewrite, který umožňuje aplikovat na volané URL pravidla, jimiž lze dynamicky měnit cestu do cílového adresáře.
Úspěšná autentifikace je nezbytnou podmínkou k tomu, aby mohla být správně interpretovaná absolutní cesta do uživatelského adresáře, neboť v pravidle pro mod_rewrite se pracuje s obsahem proměnné REMOTE_USER, což je uživatelské jméno přihlášeného uživatele.
Tento uživatel přitom vůbec nemusí existovat v operačním systému serveru. Pochopitelně lze použít autentifikační mechanismus, který umí ověřit uživatele vůči lokálnímu účtu, ovšem z bezpečnostního hlediska je to hovadina, neboť by tím při eventuální kompromitaci přihlašovacích údajů získal potenciální útočník přístup ke konzoli, což by jenom zvyšovalo riziko, že bude stroj nabourán.
Pro autentifikaci uživatelů je tedy lepší využít nějaký jiný mechanismus. Optimální je využít LDAP, ale pro menší skupinu uživatelů je zbytečné rozjíždět vlastní LDAP server, když bohatě postačí, podobně jako při testování, basic ověření uživatelského jména a hesla vůči souboru spravovanému přes utilitu htpasswd.
Z hlediska bezpečnosti je mnohem důležitější aby byla komunikace mezi klientem a serverem šifrovaná přes SSL, než to jaký je použit autentifikační mechanismus. Kvůli zjednodušení však následujícím příkladu uvádím ukázkovou konfiguraci pro nešifrovanou komunikaci!
Kde a s jakým jménem bude soubor s hesly uložen, je vcelku jedno. Musí být splněna pouze ta podmínka, že uživatel, pod kterým běží webový server z něj bude moci číst. Utilita htpasswd, kterou lze použít k jeho vytvoření je v Debianu součástí instalačního balíčku apache2-utils
htpasswd -c -m /etc/dav/htpasswd.setup user1 htpasswd -m /etc/dav/htpasswd.setup user2 ...
Pozn.: V uvedeném příkladu jsem vnutil parametrem -m použití MD5 algoritmu, protože jsem stejný soubor používal i pro autentifikaci u radicale a jak jsem zjistil z jeho výpisu, klient z BlackBerry posílal k ověření heslo kryptované přes MD5.
Uživatelské adresáře, které se budou dynamicky mapovat podle uživatelského jména přihlášeného uživatele, mohou být kdekoliv v systému, nejlépe však zcela mimo strukturu adresáře /var/www, což je výchozí hodnota proměnné DocumentRoot u Debianu.
mkdir -p /srv/dav/user1/.DAV mkdir -p /srv/dav/user2/.DAV ... chown -cR www-data /srv/dav chmod -cR 660 /srv/dav
Aby bylo možné s obsahem těchto adresářů namountovanými přes WebDAV pracovat, musí mít uživatel pod kterým běží webový server (u Debianu www-data) právo nejenom ke čtení, ale i k zápisu do těchto adresářů.
POZOR! Pokud by adresář, který má být dostupný přes WebDAV ,obsahoval soubor, ke kterému by neměl uživatel pod který běží webový server přístup alespoň pro čtení, skončil by pokus o vytvoření nového souboru chybou.
Poznámka: Pokud by neexistoval adresář .DAV, skončil by pro změnu pokus o namountování na straně klienta oznámením, že cílová lokace není dostupná přes WebDAV.
Aby server ověřoval uživatele vůči obsahu souboru /etc/dav/htpasswd.setup, musí být do Apache zaveden modul mod_authn_file, který zajistí, že bude rozumět syntaxi tohoto souboru a také autentifikační modul mod_auth_basic, pro základní ověření kombinací uživatelské jména a hesla.
root@stroj:~# cat /etc/apache2/conf-available/dav.conf
RewriteEngine On
<Directory /srv/dav>
DAV On
DirectoryIndex neverused.neverused
</Directory>
<Location /webdav>
AuthType Basic
AuthName "WebDAV"
AuthBasicProvider file
AuthUserFile /etc/dav/htpasswd.setup
Require valid-user
</Location>
RewriteRule ^/webdav/(.*)$ /srv/dav/%{LA-U:REMOTE_USER}/$1
Autentifikace uživatele probíhá vůči elementu Location. Ačkoliv na internetu naleznete příklady, ve kterých je autentifikace přítomna v obou elementech, tak z vlastní zkušenosti mohu říct, že vám to pak přestane fungovat. Fungovalo by vám to pouze v tom případě, že byste chtěli adresář, který je v elementu Directory publikovat přes web. Jenže pak na tom zase pro změnu nerozběháte WebDAV.
Také upozorňuji na direktivu DirectoryIndex v elementu Directory. Ta slouží k tomu, aby při přístupu přes WebDAV nedocházelo k nežádoucí interpretaci souborů typu index.html. Pokud byste ji konfiguraci neuvedli, tak v případě, že uživatel vytvoří v podadresáři soubor index.html dojde k jeho interpretaci a obsah adresáře bude nedostupný. Přesto že na serveru normálně bude existovat a dokonce bude fungovat i upload.
Tuto vytvořenou konfiguraci bude Apache akceptovat po restartu.
Jako příklad uvádím pouze namountování vypublikovaného adresáře uživatele user1 přes davfs.
mount -t davfs http://stroj/webdav /pripojny_bod -o username=user1
Na platformě MS Windows je třeba od MS Windows Vista výše provést nejprve drobnou úpravu v registru, jinak nebude autentifikace jménem a heslem fungovat. Pak již lze normálně použít volbu "Připojit sdílený disk". Reg soubor který tuto změnu udělá, resp. popis kde se má co změnit, včertně nějakých obrázků najdete na naší wiki.
Podobným způsobem se připojení sdílený disk i u Mac OS X, až na to, že nevyžaduje opruz s opravou záznamu v registru.
Na BlackBerry Q10 používám pro připojení adresáře sdíleného přes WebDAV placenou aplikaci PlayCloud a na Androidu můžete použít kupříkladu aplikaci ES file explorer.
Při pokusu o otevření URL http://stroj/webdav v prohlížeči skončí webový prohlížeč na chybě 403 a to i přes úspěšnou autorizaci.
Chcete-li obsah uživatelských adresářů vypublikovat tak, aby byl dostupný (pouze ke čtení) i přes webový prohlížeč, můžete vytvořit do adresáře /var/www symlink, kupříkladu s názvem pub, který bude na /srv/dav odkazovat.
Tiskni
Sdílej:
18.12.2014 16:03
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
19.12.2014 14:55
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
19.12.2014 17:07
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Nový proces pro každý request se vytváří právě u suexec.Tak to fakt ne. Možná se bavíme každý o něčem jiném - já mluvím o nastavení, kdy apache přes suexec spustí program a ten pak běží jako FastCGI server.
Jinak může proces Apache vyřídit prakticky libovolný počet požadavkůPravda, tohle jsem si zaměnil s CGI - co koukám do dokumentace, tak i prefork režim nechá jeden (pod)proces vyřídit víc požadavků.
Další věcí je, že suexec se týká jen toho, co se po Apachem spouští, kdežto mpm_itk se vztahuje na všechno včetně samotných funkcí Apache.To je pravda, na druhou stranu ty samotné funkce Apache toho neřeší tolik - přijmout navázané spojení, otevřít soubor, načíst soubor, poslat obsah do toho spojení - na tom není moc co zkazit a i tak se to děje pod neprivilegovaným uživatelem. Za poslední roky přitom nevím o nějaké chybě, která by v tomhle režimu umožňovala vykonat cizí kód nebo aspoň přistoupit k cizím datům.
19.12.2014 18:29
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
já mluvím o nastavení, kdy apache přes suexec spustí program a ten pak běží jako FastCGI serverTo už je ale trochu něco jiného. Samotný suexec se chová tak, jak jsem popsal.
i prefork režim nechá jeden (pod)proces vyřídit víc požadavkůMůže jich vyřídit libovolné množství, pokud se Apache tak nastaví. Při běhu pod více uživateli je tam samozřejmě ten problém, který jsem zmínil. Pokud je k dispozici dost paměti, dá se limit na procesy Apache nastavit vysoko (totéž počet flákajících se procesů, aby je to neukončovalo) a nevzniká zpoždění tím, že by se vytvářely nové procesy.
To je pravda, na druhou stranu ty samotné funkce Apache toho neřeší tolik - přijmout navázané spojení, otevřít soubor, načíst soubor, poslat obsah do toho spojení - na tom není moc co zkazit a i tak se to děje pod neprivilegovaným uživatelem.Jenže řeč byla o WebDAV, z toho celou dobu vycházím.
Tedy namísto jednoduchého řešení typu mpm-itk, kdy celá obsluha probíhá pod příslušným uid/gid, zvolíme komplikovanéVáš názor, nic jiného.
(a tedy potenciálně děravé),FUD, navíc vycházející z nepravdivého předpokladu
dost možná ještě méně výkonné řešení.Tak jsem si to lehce otestoval - výchozí instalace Apache, statický obsah (stránka s It works) na localhostu s prefork + itk vs. event nebo worker. Worker cca 6000 req/s, prefork 1000 req/s.
Nevím, jak takovou prasárnu může vůbec někdo vychvalovat.Asi to bude někdo, komu nastavení suexec nedělá problémy a výsledek bez problémů funguje. Ten někdo se možná podíval do zdrojáku suexec, který je pochopitelný a je z něj naprosto jasně vidět, co to dělá a proč.
19.12.2014 17:11
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Tak jsem si to lehce otestoval - výchozí instalace Apache, statický obsah (stránka s It works) na localhostu s prefork + itk vs. event nebo worker. Worker cca 6000 req/s, prefork 1000 req/s.To je ale zjevně něco úplně jiného, než o čem tu je řeč. Worker a event nezajistí samy o sobě separaci uživatelů (třeba pro WebDAV, o kterém je tu řeč od počátku), takže tohle porovnání výkonu je nesmysl. Srovnává se nesrovnatelné.
Worker a event nezajistí samy o sobě separaci uživatelůAno, to je mi známo, goto #1, první věta. Kdyby ten webserver byl jenom osobní datové úložiště (tak, jak ho popisuje autor blogu), tak fajn. Na takovém serveru nebude velký provoz. Jenže v konfiguraci, kdy je Apache primárně webserver (čti server poskytující webové stránky webovým prohlížečům, goto #1, druhá věta), už je to něco jiného - tam si pomalý prefork nemůžu dovolit, což potvrzuje i to srovnání. Jasně, separaci uživatelů worker ani event nezajistí, takže WebDAV je ze hry venku a jsem odkázaný na FTP, SFTP apod.
Worker a event nezajistí samy o sobě separaci uživatelů (třeba pro WebDAV, o kterém je tu řeč od počátku), takže tohle porovnání výkonu je nesmysl. Srovnává se nesrovnatelné.+1
Jinak základní podporu pro WebDAV je možné poměrně jednoduše zbastlit i v PHP a to dokonce tak, že jedno URL při přístupem přes normální prohlížeč ukáže nějakou "sexy" stránku např. s výpisem adresáře a přitom přes stejné URL je to dostupné přes WebDAV...Nebo použijete standardní moduly pro Apache, které udělají totéž
No nekteri z nas ten WebDAV na FELu museli pouzivat jako studenti, a ze by to byla tak super vec, to mi uplne neprislo.O WebDAV, který jsem provozoval já jde asi těžko. Bylo to čistě provizorní řešení, určené ke sdílení souborů v rámci jedné pracovní skupiny a konfigurace byla vskutku jen základní. Pravděpodobně jde asi o řešení, které bylo donedávna provozované na Katedře počítačů. Podle toho co mi o něm sdělil kolega byl největší zádrhel ve zbytečně komplikovaném URL a v tom k čemu byl tento sdílený prostor určen. Nefungovalo to tak, že by měl každý student jeden adresář dostupný přes WebDAV, do kterého by si ukládal svoje soubory, ale zakládal se mu adresář extra pro každý předmět. S tím, že tento adresář byl určen pouze pro odevzdávání souborů souvisejících s předmětem. A jelikož vyučující předmětu k nim musel mít také přístup, tak z toho plynul onen oser s konfigurací práv. A s tím vcelku souhlasím, že to musel být opruz, protože WebDAV nějaké sofistikované nastavení práv vůbec neřeší. Taky se nehodí ani pro uložení uživatelského profilu, protože nelze kupř. pracovat se symlinky. Ovšem pro to, aby měl své každý uživatel dostupné své dokumenty po síti souběžně z různých zařízení, podle mě bohatě stačí.
Coz treba Moodle, ktery se v te dobe zacal sirit, a obcas mi prisel z uzivatelskyho hlediska fakt tragickej (kam se mam sakra zas proklikat), tak tuhle administrativni pripravu mel zrejme lip zmaknutou.Pokud jde o Moodle, tak že jde o zcela tragický e-learningový systém se nebudu přít. Už jsem se o tom možná tady někde i zmiňoval co vše na něm považuji za špatné - v podstatě to začíná už samotným návrhem aplikace, která nezapře své kořeny v jednoúčelovém bastlu, jehož autor vůbec netušil že se to zvrhne do takového molochu. Bohužel. Stalo se a trend je takový, že s ním bude nutné žít i do budoucna.
[...], protože nelze kupř. pracovat se symlinky.Dobré vědět. Doteď jsem si dělal naděje, že by WebDAV šel použít na sdílení dat mezi mými zařízeními, ale chybějící podpora symlinků je na mne příliš omezující.
22.12.2014 02:30
brozkeff | skóre: 13
| blog: Zpátky po 10 letech
| Žďár nad Sázavou
WebDAV využívá i třeba ownCloud, takže pokud nejde o levný hosting za 20 korun měsíčně, ale výkonnější VPSko, tak bych pro jednoduchost možná zvážil i ten owncloud, kde je možnost to napojit na LDAP či AD, nebo vytvářet uživatele a skupiny ručně.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
19.12.2014 11:20
18.12.2014 14:56
19.12.2014 12:34
21.12.2014 01:00