Názory k článku
Dropbox vydal novou verzi, která v Linuxu vyžaduje nešifrovaný ext4
-
AK (neregistrovaný)
Pokud ten článek chápu správně, tak tohle se týká především lidí, kteří nechápou, jak má vůbec šifrování fungovat.
Přes ten dropbox se mají přenášet šifrované truecrypt kontejnery... ;)
Pro dropbox to pak vypadá tak, že neustále synchronizuje nesrozumitelný binární soubor, který je uložen třeba na nějakém ext4. -
Michal SmržStříbrný podporovatelGrrrr. Léta jsem chválil Dropbox, že nemá největší kapacitu a další věci, ale "prostě funguje". Tak fungovat přestal, veselé.
-
Jenže tohle vůbec nesouvisí s tím, jestli se šifrovaná data nahrávají do Dropboxu. Tohle pořád jde, pokud jsou to data v nějakých souborech. Jde o souborový systém, ze kterého Dropbox ta data čte. Ten nesmí při zápisu na disk používat šifrování, jinak z něj Dropbox odmítne synchronizovat. I když jsou pro něj soubory normálně čitelné.
-
Lze to poznat, pokud ta šifrovací vrstva maskuje některé vlastnosti souborového systému. Je to popsáno v odkazovaném článku. Pokud leží šifrování pod souborovým systémem (LUKS), tak to samozřejmě nelze poznat.
-
KateStříbrný podporovatelAch jo… Šifrované soubory na ext4 samozřejmě uploadovat na dropbox půjde. Stejně jako to bude fungovat na ext4 na luks oddílu. (protože tam jsou ty soubory přímo na ext4 a dropbox mezivrstvu která je až pod tím nevidí)
Tady jde třeba o ecryptfs, tedy vrstvu šifrování nad souborovým systémem. A synchronizovat nepůjde soubory které jsou aktuálně v dešifrovaném stavu, takže je tam vrstení dešifrovaný soubor -> ecryptfs -> filesystém.
-
KateStříbrný podporovatel
Jinak řečeno, titulek zprávičky je špatně. Dropboxu je úplně jedno jestli se šifruje nebo ne, jen odmítá běžet na něčem jiném než ext4. Ecryptfs nebo encfs stackovaný nad ext4 odmítne, protože to není ext4. Pokud se pod ext4 strčí luks oddíl, je to z hlediska Dropboxu v pořádku. Pokud se na ext4 vyskytnou jednotlivé šifrované soubory tak pochopitelně taky.
To že je to z hlediska Dropboxu blbost tak jak je to tak je jasné, ale nemusíme hned rozjíždět konspirační teorie o Dropboxu co chce bránit šifrování.
-
Filip JirsákStříbrný podporovatelZáležet by na tom nemělo, ale Dropbox to má údajně implementované tak, že používá nějaké ID souborového systému (snad tím něco šifrují). No a tohle ID se třeba u XFS mezi připojeními souborového systému mění, zatímco u ext4 je neměnné. Takže to není žádný záměr omezovat uživatele na konkrétní souborový systém nebo snaha bránit šifrování či kdovíco ještě. Pouze si ulehčili práci a jeden údaj použili k něčemu, k čemu sloužit nemá, vyšli z předpokladu, že se ten údaj nemění – a pak museli omezit použití na ty souborové systémy, kde se ten údaj opravdu nemění. Pokud se změní implementace ext4 a to ID se bude mezi připojeními souborového systému měnit, přestane Dropbox fungovat i tam.
-
KateStříbrný podporovatel
Každopádně je to diletanství nejhrubšího zrna a o vedení toho projektu to vypovídá dost. Místo aby se chyba opravila, přestanou podporovat místa kde k ní dochází… Myslím že docela dobrý důvod dát od toho ruce pryč, kdo ví jak přistupují třeba k bezpečnostním opravám.
-
Filip JirsákStříbrný podporovatel
Nemyslím si, že by to byla chyba. Podle mne je snaha udělat to pro uživatele bezúdržbové, a tohle je prostě daň za to, kterou jsou zaplatit. Pravděpodobně vědí, že to většina jejich uživatelů používá na ext4. I když mi není jasné, co a proč tam vlastně tímhle ID šifrují, a proč si místo toho nepřidají nějaký x-attribut na kořenovou složku.
-
KateStříbrný podporovatel
Pokud používám na ukládání metadat něco co podle specifikace nemusí být neměnné (a následně zjistím že se to v některých případech opravdu mění) to chyba podle mě je. Ukládat se to dá i jinak :)
Tady si ovšem dovedu představit manažerské rozhodnutí, kdy se rozhodovalo mezi opravou (s určitou časovou nákladností a problémy s konverzí stávajícího stavu) a omezení podpory. Což mi přijde trochu nešťastné. Pokud vím, RHEL i SLED používají na home XFS a Ubuntu šifruje home přes ecryptfs, takže si tím úspěšně zabíjí korporátní klienty.
Hlavně je škoda že tam nenechali nějakou volbu „aktivovat na vlastní riziko“.
-
Filip JirsákStříbrný podporovatel
Když ona specifikace neříká nic o tom, že to nemusí být neměnné. Já bych si uniquely determines a file asi taky vyložil tak, že se to pro jeden soubor nemění.
The general idea is that f_fsid contains some random stuff such that the pair (f_fsid,ino) uniquely determines a file. Some operating systems use (a variation on) the device number, or the device number combined with the filesystem type. Several operating systems restrict giving out the f_fsid field to the superuser only (and zero it for unprivileged users), because this field is used in the filehandle of the filesystem when NFS-exported, and giving it out is a security concern.
Ale proč trvají na tom, že
fsidbudou používat, i když už vědí o tom, že se mění, tomu nerozumím. -
Korporace je tvůj přítel (neregistrovaný)
Ono jenom spustit se startem win10 Dropbox je stresující záležitost - ostaních 100 programů a služeb nepozorovatelně naběhne, pak nastoupí Dropbox: plocha problikne jak se restartuje explorer, osm jader začne pracovat na 40-50%, pokud se nedejbože updatuje, záhadné soboury update a dropbox-client se dožadují na firewalu přístupu na internet, když je zakážu a ukončím, Dropbox stejně updatne a mičemu ukončení parazitů nevadí, explorer ještě jednou dvakrát restartne, cpu různě kolísá mezi 5-80%...
Kdyby to tak dělaly všechny procesy, tak snad přejdu na Linux. -
Pá pá dropbox (neregistrovaný)
Možná jsem měl volit méně silná slova. Není to nic proti ničemu. Sám syncthing i nextcloud delší dobu používám. Ale, co mi připadne že se syncthing hodí spíš na sync živých dokumentů. Dropbox/owncloud je pro mě úložiště, rozuměj odkladiště. Chci mít všude dostupný dokument který zrovna píšu, použiji syncthing, naopak chci mít někde uložené 5gb fotek, na které se podívám 1 ročně, ale nechci být limitovaný odkud, hurá s nimi do owncloudu(dropboxu).
-
Ondřej KolínZlatý podporovatel
Vyprdnete se na ne a prejdete na Nextcloud. Za par kacek si muzete nechat rozjet vlastni Nextcloud instanci nekde jinde, pokud chcete za kazdou cenu posilat data nekam jinam a nemate cas/chut babrat se s vlasnim serverem.
-
V souvislosti s šifrováním je důležitá informace, že se to týká mezivrstvy mezi FS a klientem (např. ecryptfs). S LUKSem to samozřejmě funguje.
Jinak vše zlé je k něčemu dobré:
1) takovéto kroky udržují uživatele v bdělosti
2) donutilo mě to konečně přeLUKSovat všechny své dosavadní ecryptfs složky a truecrypt kontejnery
- ecryptfs má min. v aktuálním ubuntu nepříjemný a neřešený bug komplikující otevření starých šifrovaných složek
- původní truecrypt nejde už nijak normálně stáhnout a veracrypt myslím není zpětně kompatibilní -
pepazdepa (neregistrovaný)
syncthing reference - nesmyslna, syncthing syncuje iirc dva propojitelne a ONLINE stroje, dropbox je uloziste, ke kteremu se klienti pripojuji. takze abyste mohli pouzivat syncthing jako dropbox, museli byste mit treti stroj nekde neustale online a k nemu vse syncovat.
kdyby git-annex nebyl v haskelu a orientovany na geeky, tak by to byla lepsi alternativa.
-
Syncthing může fungovat úplně stejně jako Dropbox. Mám někde jeden běžící stroj (čili server), ke kterému se připojují ostatní (čili klienti). Ovšem nemusím to tak mít, můžu nechat jen klienty, aby synchronizovali mezi sebou. Můžou se potkávat na lokální síti nebo synchronizovat přes internet. Je to velmi univerzální řešení, které se dá nasadit mnoha různými způsoby a neomezuje se jen na jeden.
-
B2 (neregistrovaný)
Ne že bych proti Syncthing něco měl, lokálně jej běžně používám na sync a je to super tool, ale bohužel není zdaleka tak odolný jako ten zatracený Dropbox. Ten sesynchronizuje Linux, macOS, iOS, Wokna zcela bez řečí a problémů, ošéfuje i místně obvyklé metadata soubory, při případné kolizi se udělá výrazně přejmenovaná kopie souboru (s v závorce uvednými údaji o kolizi a odkud přišla). Dostupnost dat na mobilu j jedna ze silných stránek, často jediný důvod proč něco do Cloudu vůbec cpát. Kolize se Syncthing jsou bolestné, několikrát se mi stalo, že jsem musel sync složku ze Syncthing odebrat a zase přidat, protože trval na něčem co už nebylo možné sesynchronizovat a prostě jsem nenašel jinou cestu jak udělat stav na 100% synchronizovaný.
Jako kuriozita mi mmch připadá fakt, že nelze mít Dropbox složku na NTFS partišně pod Linuxem (ne že by to zase tak moc vadilo), přitom pod Windows je to základní FS. :-)
-
Adam (neregistrovaný)
No - mně to docela dost vadí, protože mám několik strojů, kde se přechází mezi Windows a Linux (Win10/Ubuntu) a doteď šlo mít některé "home podadresáře" společné na jedné (NTFS) partition, jen symlinkované - a to včetně složky pro Dropbox. Oddělit je samozřejmě lze, ale má to dvě nevýhody:
a) každý uživatel tam bude mít těch několik GB dvakrát (a bude třeba zvětšit ext4 partition s /home, kde zatím byly hlavně symlinky) a
b) přepnutí mezi systémy bude znamenat stahování dat z Dropbox serveru, byť ta leží "hned vedle" - s potenciálem vzniku kolizí, když se něco změní, než synchronisace doběhne (o neblahém vlivu FUP stropu nemluvě). -
Adam (neregistrovaný)
Díky za dobrou radu.
Ale někdy si situace a "historický vývoj" prostě takhle blbé nastavení přinese s sebou.
Jestli máte někdo nápad, jak to udělat lépe, tak sem s ním. Žel, dokud budou něktré organizace trvat na používání Windows-only řešení a zároveň uživatelé používají většinou Linuxové programy, dualbootu se nevyhnu.
A Dropbox byl pro spolupráci "virtuálních teamů" také dobré řešení (a zatím těžko nahraditelné, protože jsou na to naučení i externisté). -
vládík (neregistrovaný)
mít to na jednom systemu třeba linux ext4 a z windows k tomu přistupovat přes ovladač ext2fsd a sinc se bude provadět jenom pri spuštení linuxu (pokud tomu nebude stačit WSL ůdajně je docela použitelný ale asi nebude) což na což stací jen mít ve windows nejakou obdobu "sudo qemu-system-x86_64 -enable-kvm -m 1G /dev/sda" ale ext4 není zrovna thread safe tady alespon ne by default
a nebo podobným způsobem spouštet windows v qemu za ůčelem synchronizace ale tam asi bude problém s licencemi -
k3dARStříbrný podporovatelreseni je snadne, vykaslat se na dualboot, mit nativni GNU/Linux, v QEMU Windows a spolecne data mit na ext4 (nebo co v GNU/Linuxu pouzivas) ke kterym Windows z QEMU polezou pres Sambu (nebo pokud to uz Win umej/nevim tak sdilenej adresar, ale to snad umi jen v GNU/Linux pres 9p http://www.linux-kvm.org/page/9p_virtio)
-
k3dARStříbrný podporovatel
pripadne misto QEMU (myslel sem tim virt-manager(KVM/QEMU)), pouzit "chudeho pribuzneho" VirtualBox, kterej sdilene slozky s Win virtualem tusim umi a navic ma "bezesvej rezim" coz nekomu pouzivajici casto Win aplikace muze vyhovovat...
-
B2 (neregistrovaný)
Já to měl tak také (společnou složku na NTFS partišně), ale nedalo se svítit, složka Dropbox šla do home. Stejně ta Windows bootuju už tak málo, že mě to zase tak moc nebere, ani těch 5 GB dat. :-) Pozitiva "krabice" pořád převážila nad tímto zvláštním opruzem. Pokud má někdu Bussines účet s terárkem dat, tam už to může být otrava to mít a synchronizovat zbytečně dvakrát.
-
k3dARStříbrný podporovatel
Dropbox nepouzivam, ale mozna ti uniklo nekolikrat zminene info, ze pri pouziti sifrovani POD filesystemem (LUKS) problem neni, pouze pri pouziti sifrovani NAD filesystemem (EncFS, eCryptFS), coz je obecne lepsi nepouzivat a pouzivat prave LUKS ;-)
-
k3dARStříbrný podporovatel
protoze tva otazka vyzni jako "me to funguje, co vam?" tak mi prislo normalne te upozotnit na neco co si asi prehledl, myslim ze ma reakce byla relevantnejsi nez tato tva, ale klidna si dal placej pres rameno jak si mi to nandal ;-)
ČLÁNKY DO MAILU