Vlákno názorů ke zprávičce Dropbox vydal novou verzi, která v Linuxu vyžaduje nešifrovaný ext4 od R223 - Šifrovaná data se špatně "analyzují". Co kdyby tam...

Ach 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.

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í.

Zá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.

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.

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.

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“.

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 fsid budou používat, i když už vědí o tom, že se mění, tomu nerozumím.