Pro me tohle bylo prekvapenim, kdyz jsem zjistil ze macos si drzi tuhle informaci o stazeni souboru nekde z internetu. Prvni vec co jsem udelal je, ze tyhle informace odstranuji skriptem ze vsech stazenych souboru a stazene soubory nezalohuji a neindexuji. Co koho do toho kde jsem nejaky soubor stahl? Chapu, ze nektere aplikace umi tuhle informaci vyuzit (treba antivir), ale jako uzivateli se mi to vubec nelibi. Podle me se jedna o zasah do soukromi uzivatele.
Nevím jak moc velký zásah do soukromí je informace tom, ODKUD člověk něco stáhl, když už celý operační systém ví, CO stáhl. Připadá mi to jako užitečná věc: stahuju něco velkého, trvá to dlouho a stahování se přeruší, tak je dobré na nedostaženém soubouru mít hned URL, odkud je. Nebo si stáhnu ISO, za šest měsíců chci zkusit, jestli nevyšla nová verze, tak je dobré se nemuset znovu proklikávat webovými stránkami (totiž pokud si člověk ještě pamatuje, odkud to vlastně bylo, a nemusí to vyhledávat na Googlu, což je zásah do soukromí mnohem větší). Totéž platí o zsync apod.
1. tak treba stahnete neco na externi disk se spravnym fs, ten disk date kolegovi a on vi odkud jste to stahnul (jeho OS to nevi, ale vi to z disku)...
2. v url muze byt neco co vas identifikuje a nechcete to ukazovat vsem (treba muj nick na root.cz)
3. nechcete aby u souboru "invoice for media streaming services.pdf" bylo v metadatech ze jste to stahl ze sickpornsite.com
atd.
Nekomu nevadi ani sdileni rozpracovanych dokumentu wordu s microsoftem, nekomu to vadi. Nekomu nevadi ukladani URL stahovaneho souboru, nekomu to vadi. ;)
URL by nemělo obsahovat identifikátor surfaře. To že URL v reálu takové věci obsahuje (nick, sessionid, ...) je dle mne chyba.
Faktem je, že i když URL takové věci obsahovat nebude, může ledacos z webu odhalovat (může naznačovat jaký další obsah se na webu nachází) a to může u interních webů vadit.
Také URL ve spojení s vhodným časem (?modifikace) může identifikovat surfaře, který soubor začal šířit - tedy jen pro ty co mají log web serveru.
Zdá se mi, že může jít o užitečnou vlastnost pokud půjde vhodně zajistit, že atribut zmizí, když soubor opustí disk na který byl stažen (respektive u přenosných disků nebude ani ukládán). No má to své problémy...
Nautilus a předpokládám, že i správci souborů z jiných desktopů, umí pracovat s Trackerem, takže jedna cesta by asi byla implementovat do Trackeru funkci, aby indexoval soubory i podle XDG atributů.
Anebo něco na úrovni VFS, jako byly Queries v BeOS. Přinejmenším do upstream jádra by se něco takového dostalo asi jen přes Linusovu mrtvolu, ale i tak by šlo mít nějaký pseudoadresář ovládaný přes FUSE, se všemi soubory roztříděnými podle atributů.
On název "Atribut" je v případě Windows zavádějící. Tam se to jmenuje Stream (velmi pěkný popis) a lze tam narvat cokoli, o jakékoli velikosti a může jich být více.
Zákeřné je to v tom, že standardní nástroje a většina správců souborů je vůbec neukazuje a ani se nemění udávaná velikost původního souboru (což je zle z principu, jak se ukládají OK).
Příklad: Vytvořím si textový soubor test.txt s obsahem 123456
C:\Temp>echo 123456 >test.txt
Velikost má 9 byte:
C:\Temp>dir
27.12.2018 06:21 9 test.txt
Obsah je očekávaný (na konci je mezera + CRLF):
0000000000: 31 32 33 34 35 36 20 0D │ 0A 123456
Teď do streamu k tomuto souboru, který si pojmenuji "stream1", přidám např. výpis z nslookup:
C:\Temp>nslookup portal.gov.cz >test.txt:stream1
Ještě třeba do streamu s názvem "stream2" přidám obsah www.root.cz:
C:\Temp>D:\Programy\#Internet\CUrl\curl.exe www.root.cz >test.txt:stream2
Velikost souboru se ale stále nezměnila, datum zápisu ano:
C:\Temp>dir
27.12.2018 06:24 9 test.txt
Když se na to podívám nějakým nástrojem (např. Streams ze Sysinternals nebo AlternateStreamView or NirSoft), který se streamy umí pracovat, tak je ukáže:
C:\Temp>D:\Programy\#System\SysInternals\streams64.exe C:\Temp\test.txt
streams v1.60 - Reveal NTFS alternate streams.
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\Temp\test.txt:
:stream1:$DATA 214
:stream2:$DATA 305
Takže je vidět, že v souboru test.txt jsou dva streamy, stream1 s velikostí 214 byte a stream2 s velikostí 305 byte.
Obsah souboru se ale pro standardní nástroje nezměnil:
C:\Temp>more test.txt
123456
Vypíšu si obsah streamů.
stream1:
C:\Temp>more <test.txt:stream1
Server: dynamic-2a00-1008-81d8-1ac2-0000-0000-0000-0001.ipv6.broadband.iol.cz
Address: 2a00:1018:81dc:1aba::1
Name: gov.cz
Addresses: 2a03:2320:b944:1c60::96
185.68.28.96
Aliases: portal.gov.cz
stream2 (před konce tagů jsem dal #, aby to root.cz nechápal jako řídící tagy):
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"#>
<html#><head#>
<title#>301 Moved Permanently</title#>
</head#><body#>
<h1#>Moved Permanently</h1#>
<p#>The document has moved.... (zkráceno)
Klidně mohu vytvořit soubor s velikostí 0 byte, ve kterém nic nebude a vše bude "schované" jen ve streamech. Ale streamy přežijí pouze v rámci NTFS. Když se soubor se streamy překopíruje např. na Google Drive (nebo na flash s FAT32), tak o ně přijde.
Velikost souboru znamená velikost primárníáho (nepojmenovaného) streamu. Na ty pojmenované se musíte zeptat zvlášť. A ano, je potřeba externí utility.
> Ideální způsob jak skrýt nějaká data.
> Vytvořím soubor recept.txt s receptem na svíčkovou. Přitom si do tohoto souboru
> umístím recept na výrobu drogy.
> Koho by z expertů (policii apod) napadlo se podívat do streamu.
Tahle vlastnost je již velmi velmi dlouho známá. Dokonce i ve světě malware. Takže jako schovka nic moc extra.
Pokud se chceme přiblížit pojmu "atribut", je třeba se podívat na tzv. rozšířené atributy (extended attributes). Případně by něco šlo uložit jako reparse point (standardně se tam ukládají symlinky, ale ten mechanismus je obecnější).
Žiji jsem v představě, že NTSF streamy jsou jen jeden z dalších možných uložení "tajných" informací o souboru. Ovšem, že stále ještě existují i klasické rozšířené atributy (z dob OS/2) a je to něco jiného než stream.
Pro současné windows však nejsou přístupné přímo z user API, musí se asi níže. K nastavení jsem kdysi tuším zkoušel (undocumented? tenkrát?) NtSetEaFile a teď by snad měla být (documented?, co jsem v rychlosti našel na netu) obdoba ZwSetEaFile. https://msdn.microsoft.com/en-us/library/windows/hardware/ff961908%28v=vs.85%29.aspx
Microsoft extended attributes, tuším, sám o sobě nově oživil ve WSL, kde si tam ukládá *nix-like vlastnosti souborů. A mám pocit, že tam při tom něco zblbli a snad už i proběhla oprava a mělo by být ok. Tedy, pokud nezmatkuji a nespletl jsem dohromady dvě různé věci. Oživili právě proto, aby se rozšířené informace neztratily, když k souborům přistupují paralelně z WIN32 i WSL.
Ale v principu, pokud by někdo chtěl (ale asi jen na driver úrovni?, pro win32, WSL netuším), asi by mohl přidat "tajné" rozšířené atributy i nyní. Ještě mino streamy.
> Žiji jsem v představě, že NTSF streamy jsou jen jeden z dalších možných uložení
> "tajných" informací o souboru. Ovšem, že stále ještě existují i klasické rozšířené atributy
> (z dob OS/2) a je to něco jiného než stream.
Ano, WSL je používá. Pak jsem jejich použití viděl u rozhraní Transport Driver Interface (TDI), což jsou takové "sockety" pro ovladače (naštěstí od Windows Vista deprecated). Tam se myslím používaly pro specifikaci IP adres. Je ale pravda, že tyhle atributy nikdy neviděly disk.
NtQueryEa/NtSetEa by jde volat i normálně z usermode, ač je pravda, že tyhle nízkoúrovňové API (jde vlastně o systémová volání) jsou dokumentovány zejména pro potřeby ovladačů. Pokud vytváříte nový soubor, tak je ani nepotřebujete, protože systémové volání NtCreateFile vám dovoluje rozšířené atributy přímo specifikovat.
Na rozdíl od alternativních datových proudů mají ale rozšířené atributy omezenou velikost
(celkově max. 64 KB pro jeden soubor?), takže se nehodí na všechno.
Necítím se být "v počítačích" zrovna nováček, přesto jsem o xattr neměl ani tušení. Prvotní dojmy: to je strašně nebezpečná fičura! A to ne zrovna jen v kombinaci s uloženou URL, ale může tam být cokoliv a nikdo neví co, nikoho nenapadne to zjišťovat. Odteď když budu chtít na někoho ušít malware, bude se ukládat právě tam.
Dotaz: jak vytvořit ext4 filesystém s vypnutými xattr?
Podnět pro redakci: co takhle nějaký osvětný článek o xattr obecně?
Tak zpět, co to teď zkouším, tak v současnosti mi to už zapíná atributy i bez "user_xattr" (aktuální Gentoo). Ale "nouser_xattr" každopádně funguje:
~ # mount /dev/vg/test /mnt/test/
~ # getfattr -d /mnt/test/*
getfattr: Odstraňuji úvodní „/“ z absolutní cesty
# file: mnt/test/pokus
user.pokus="Test"
user.pokus2="Test"
~ # umount /mnt/test/
~ # mount -onouser_xattr /dev/vg/test /mnt/test/
~ # getfattr -d /mnt/test/*
~ #
Třeba toto je taky pěkná čuňárnička
$ touch deleteme $ sudo chattr +i deleteme $ sudo rm deleteme rm: nelze odstranit 'deleteme': Operace není povolena
Nie je to prasarna. Pouzivam to, ked si nejaka aplikacia mysli, ze je mudrejsia nez spravca. Napr. Chrome si zapisuje do Cronu. Takze mu to zrusim a nastavim, aby to nemohol prepisat pri update. Dalsim prikladom je Firefox, ktory sa snazi updatovat, aj ked to mam zakazane, takze nastavim, ze sa subory Firefoxy nedaju zmenit a nazdar.
Osobně soukromá i firemní data mám na cryptovaném disku, předpokládám, že i tady jsou atributy podporované a pak je to v cajku. Samozřejmě problém to může být třeba na nějakém sdíleném disku nebo v případě auditu běžného nešifrovaného disku (oddílu).
V každém případě zajímavá informace, takže proč to nevyužít - někdy se může hodit vědet, odkud jsem to to nebo ono stahnul. Jak jsem si to teď projel, tak bohužel wget v distribuci (SuSE) mi to neukládá a ani prohlížeče (přičemž chrome/ium na stahování nepoužívám).
https://docs.microsoft.com/en-us/windows/desktop/fileio/filesystem-functionality-comparison
V skratke:
exFAT nepodporuje extended attributes (ani named streams, spomenute v diskusii vyssie)
Este doplnim, ze podla https://eclecticlight.co/2018/01/12/which-file-systems-and-cloud-services-preserve-extended-attributes/ ak na FAT32 / exFAT zapisuje macOS (X), extended attributes su ciastocne podporovane (zapisanim dodatocneho skryteho suboru).
Zajímavá věc... Projel jsem si svůj home a ani v adresáři stažených nemám jediný soubor, který by měl něco nastavené... Je pravda, že jako web. prohlížeč používám Firefox a příležitostně Vivaldi, souborový systém mám Ext4.
Ale napadá mě, že by tohle mohl být chytrý způsob, jak u souborů držet tagy, které mi na normálním filesystému dost chybí... Třeba jako rychlé vyhledávání všech fotek, které jsou otagované "dovolená" && "já" && !"milenka" ;-) a podobně... Na druhou stranu, když to není podporované tak často používaným filesystémem, jako je FAT16, tak je otázka, jestli je to použitelné...
Btw. z rychlého googlení mi není jasné, jestli tohle podporuje ISO 9660... Sice tam je položka "extended file attributes length", ale není mi jasné, jestli tam můžou být tyhle rozšířené atributy, nebo jestli je to jen pro POSIX věci (práva a vlastníka) při použití Rock Ridge... Kdyby to fungovalo aspoň na CD/DVD, tak už se o tom dá uvažovat...
btw: Vivaldi to uklada, prave ulozene iso (fs je ext4, nepridaval sem zadne mkfs, tune2fs, nebo mount options):
getfattr -d debian-9.6.0-amd64-netinst.iso
# file: debian-9.6.0-amd64-netinst.iso
user.xdg.origin.url="https://gensho.ftp.acc.umu.se/debian-cd/current/amd64/iso-cd/debian-9.6.0-amd64-netinst.iso"
user.xdg.referrer.url="https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/"