SMB3 server implementovaný v jádře s názvem KSMBD, za kterým stojí Samsung, se dostal do jádra 5.15. To ještě ani nevyšlo a už se v KSMBD objevila závažná zranitelnost, kdy pomocí znaků .. v cestě je možné přistupovat k souborům mimo sdílené adresáře.
Oprava filtrující znaky .. a . v cestě byla poslána včera. Jádro 5.15 je ode dneška dostupné jako rc2. Vydání ostrého jádra 5.15 očekáváme koncem října.
(zdroj: phoronix)
Nechci dělat borce, ale docela dost amatérská chyba na to, že to šlo do kernelu.
No, jestli ta oprava spočívala v odfiltrování "." a ".." z cesty, pak teda "potěš Pámbu!" - poměrně často používám jak "tečku", tak "dvě tečky". První, když potřebuju někde přistupovat k souborům v aktuálním adresáři a nemůžu mít cestu "prázdnou" (prptože se k ní přidává lomítko), druhé typicky pro přečtení "konfigurace" z aktuálně zpracovávaného (datového) podadresáře. Asi to není nejčistší, ale zato velmi oblíbená konstrukce.
Jestli to je "JEN" filtrování, tak to potěš koště - v takovém případě bych se ani nedivil, kdyby se pomocí nějakého vhodného kódování podařilo tento filtr obejít...
Takové techniky se nazývají "Unicode Normalization vulnerability" nebo "UTF Hacking". Často je poměrně dost obtížné vstup vyčistit tak, aby byl naprosto bezpečný. Tedy, ono to v první chvíli funguje, ale časem to někdo sprasí nebo tam přidá něco (fičůru), která to sprasí :-(
@RDa, @Lol_Phirae, @R._R._Šimek:
NFS funguje tak ako ma, ak neviete ako ho spravne pouzit, tak sa obratte na odbornika, v serverovom prostredi je pre zdielane disky pouzivany casto, samba pokial viem, nikdy. Rovnako linux NFS server - linux NFS client funguje dobre. Situacia je rovnaka aj na mac.
Ten widle nfs klient je tam myslim od 7 verzie. Pre XP bude treba windows services for unix. Mozete si od M$ zaziadat o predlzenu podporu XP, mozno to vyjde.
Vykon a moznosti nastavenia opravneni nie je problem na strane NFS. Je to problem vo widlach.
Miesto toho aby sa prisposobili a sfunkcnili widle, tak aby dokazali spolupracovat s linuxovym serverom, tak radsej rozbijeme linuxovy server a spravyme z neho podobny odpad ako windows server...
Děkuji za poučení, jehož se mi od Vás dostalo. :o)
V serverovém prostředí samozřejmě NFS používáme k plné spokojenosti a správcové Linuxů by na nás asi vzali vidle, pokud bychom tam chtěli někam dát Sambu.
Ale při připojování na desktop už to tak skvělé není, přeci jen jsou uživatelé z větší části Wokenní a připojení na pomalé lince "na velkou vzdálenost" není až taková výhra, jako když se na serveru můžete tvářit, že je ten mountpoint úplně stejnej, jako lokální disk. Desktopu proto (u nás) kraluje SMB: uživatelé z Windows s tím nemají problém, uživatelé Linuxu taky ne. Neřešíte, jestli je server okenní nebo tučňákový, neřešíte, jestli je klient wokenní nebo tučňákový - nebo jablečný.
NFS klient ve Windows (server nebo Pro nebo Enterprise) je, ale jeho používání není v tomto systému stejně přímočaré, jako ostatní. Když je potřeba zvolit jednotný způsob připojování "disků", má SMB své výhody.
Nic proti NFS.
To stale ale nie jeodpoved na to preco musi byt smb server a jeho zranitelnosti v jadre.
To ako mate zriesene spolocne ulozisko vo firme je vasa vec, ale nie je samba tak trocha zastarala? V dobe ked je mozne zdielanie suborov napriec platformami mozne bud cez cloud providera, alebo samodomo napr cez nextcloud?
Pretoze samba ako taka je uz par desiatok rokov jedna bezpecnostna diera za druhou. To ze ta varianta v jadre na tom nie je inak, dokazuje zpravicka na ktoru reagujeme. A urcite nie som sam ktory si mysli ze takato banalna, ale pri tom nebezpecna chyba nebude jedina.
Podla mna mate ale zly uhol pohladu. Ak ma linux klienta pre sambu, tak moze mat celkom dobry dovod aby mal windows klienta pre NFS ktory bude fungovat.
Preco? Ty hej?
Pre vymnenu dokumentov a podobne medzi administrativou nie je nutny sietovy file system, naozaj na to staci synchronizacia v okamihu zmien.
Tam kde je rychly suborovy system naozaj treba, sa BFU nedostanu. Tam sambu nedovoli audit.
Naviac samba sa na NFS rychlostou nechyta, pri mensich suboroch je cca 3x rychlejsi NFS, cca nad 1GB subory su porovnatelne.
Nedovedu si nějak představit, jak by sdílené dokumenty mohly výkonově položit file server, a to ani Sambu.
Těch dokumentů ovšem může být hodně a na druhou stranu, ne každý může vidět nebo měnit všechno. Takže tam máte ACL, do kterého se transformují organizační role lidí formou skupin (security groups).
Tohle se mi opravdu nezdá, jako kandidát na synchronizaci přes cloud, určitě ne kvůli výkonu nebo zátěži.
Dokumenty v cloudu mají své výhody, ale zátěž file serveru zcela jistě není to, co by hrálo roli v úvahách o použití.
Při dost velké zátěži (to vážně nedosáhnete kancelářskou prací) je Windows Server lepší. Aby se to projevilo, potřebujete ale 10gbit síťovku v serveru a odpovídající uplinky na switche - mám vyzkoušeno v dost specifické situaci.
Bude jen dobře, když se podaří Sambu výkonově přiblížit.
21. 9. 2021, 07:12 editováno autorem komentáře
To se zdaleka nehodí na všechno. Je to "jen" synchronizační nástroj. Ale často je mnohem lepší připojit si cílový disk "jako disk" a pak s tím pracovat.
Například (abych vzal něco ne zcela typického): mám foťák plný obrázků a program, který je přesype "do desktopu", ale na notebooku s malým diskem. Je jednodušší posílat to rovnou na server, než to parkovat lokálně a synchronizovat. (Ale taky je naopak lepší to na cestách sypat na lokální disk a pak synchronizovat na server. Prostě: jak kdy.)
ani ne divně, ale Samba má trochu lepší správu uživatelů a skupin.
Oba tyhle FS vznikli v 80. letech, každý má trochu jiný use case, tvrdit, že NFS je ve všem lepší a pokud něco neumí, tak to vlastně nepotřebuji je dost šílené. NFS je sice více posix, ale např. díky tomu chybí takové xattr, které i linux silně adaptoval (selinux, audit, creation time atd.), ok, pro hnipopichy, existuje RFC 8276 a zabugovaná podpora od kernelu 5.9, to ale problém zatím neřeší.
Např. Samba má obrovskou výhodu v compoudingu (spojování více příkazů v jednom packetu), umí lépe pracovat s velkými soubory, má file/directory lease (pro uživatele to je velký přínos, když mají např. otevřený dokument ve wordu či jiném editoru, který ho neustále ukládá), naprosto stežějní funkce je poté multi-channel s podporou RMDA, kdy je možné dosáhnout opravdu pěkných rychlostí na 40Gbps+ linkách. Nemluvě o nekonečném odchytávání nobody u NFS, tohle vymyslet sám ďábel.
Nfs hlavne neriesi opravnenia, ked tak riesi max mapovanie uzivatelov(ak nie je k dispozicii centralna sprava uzivatelov) a exporty. Opravnenia riesi system. Akurat linux nema mix negativnych a pozitivnych opravneni. System opravneni je pre bfu odkojeneho widlami zlozitejsi, ale admin ktoremu ide o bezpecnost hi viac oceni.
21. 9. 2021, 16:17 editováno autorem komentáře
Ak je ten filesystem zdielany, tak tie opravnenia nebudem definovat znovu, tak ako je to na urovni samby.
Proto se taky - kromě speciálních případů - doporučuje nechat oprávnění na úrovni sdílení na zápis, a řešit oprávnění ve filesystemu. Pokud chcete používat zjednodušená opravánění, pak to řešíte naopak. Filesystem všem povolený na zápis, a oprávnění na úrovni share. Když to zkombinujete, přiděláte si problémy, ale to je zhruba stejná pakárna, jako pomotat mapování uživatelů na NFS.
Mapovanie je koli tomu ze ak nemate centralnu spravu uzivatelov, tak vam pravdepodobne nebudu suhlasit id tych uzivatelov.
Ked sa vratite o par prispevkov spat, tak zistite ze akurat oponujem par ludom s potrebou riesit opravnenia cez sambu a nie na urovni systemu ktory zdielany filesystem spravuje.
System opravneni je pre bfu odkojeneho widlami zlozitejsi, ale admin ktoremu ide o bezpecnost hi viac oceni.
Jsem trochu zmaten, co tím myslíte. ACL se mapuje (via Samba) do Windows a vypadá to skoro stejně.
Jestli tou složitostí myslíte setfacl/getfacl tak jo, to je hnus, ale CLI ve Windows (cacls) je taky docela ohavnost, nemají si co vyčítat.
Jestli tím ale chcete říct, že klasická unix-like práva (chmod/chown/chgrp) dokážou nahradit ACL, tak teda ne, nedokážou. Narazíte na to už u triviální situace, že některá skupina smí něco číst, jiná tam smí i zapisovat a ostatní nemají žádné právo. Ani sticky bit to nezachrání.
Historická: nejlepší práva ve file systému měl Novell Netware. Někde v hlubinách adresářového stromu stačilo někomu přidat právo třeba na čtení jediného souboru, a tím okamžikem měl přístupnou celou cestu k tomu objektu, ale nic vedle neviděl. A v okamžiku odebrání toho práva cesta zase přestala být dostupná.
