Разработчик файловой системы Ext4 Теодор Тсо (Theodore Ts'o), работающий в компании Google, представил (http://thread.gmane.org/gmane.comp.file-systems.ext4/48206) серию патчей, добавляющих поддержку шифрования в файловую систему Ext4. Предполагается что данные патчи войдут в состав следующего релиза Android "M". Код с реализацией поддержки шифрования подготовлен совместно с Майклом Хэлкроу (Michael Halcrow (https://plus.google.com/100085619228295047055/posts)), автором eCryptFS (http://ecryptfs.org/). Дополнительно отмечается, что подготовленные патчи могут послужить основой для поддержки шифрования в файловой системе F2FS.
Реализация подразумевает (https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npa...) предоставление возможности шифрования отдельных частей ФС, например, отдельных директорий. При этом шифруется только содержимое и имена файлов, а метаданные о файлах, такие как размер и права доступа, остаются видимыми. Ключ шифрования определяется во время монтирования ФС. Настройки шифрования выполняются посредством xattr. Новые файлы или директории могут быть зашифрованы отдельно или автоматически, в случае если они создаются в уже зашифрованной директории.
Зашифрованные данные размещаются с использованием метода AES-256-XTS, для имён файлов применяется AES-256-CBC. Для каждого inode генерируется свой уникальный 521-битовый ключ шифрования, что позволяет блокировать атаки, в ситуациях когда злоумышленнику известна часть зашифрованного содержимого. По сравнению с применением надстроек, таких как dm-crypt и eCryptFS, интеграция поддержки шифрования непосредственно в драйвер ФС, позволяет добиться более высокой производительности, использовать текущий код для обработки прав доступа и обеспечить возможность работы с незашифрованной частью файлов на устаревших системах.URL: http://www.heise.de/open/meldung/Linux-Dateisysteme-Transpar...
Новость: http://www.opennet.me/opennews/art.shtml?num=42028
Не дело это. Нечего шифрованию делать в коде ФС -- шифрование это не обязанность ФС. В случае необходимости это должно делаться внешними средствами.
Чего только не придумают на волне истерии с АНБ, и прочими Б.
так это анб в истерике и придумало, а то не получается с лукса и трукрипта тырить данные народа
Причём тут АНБ?
Даже в самой новости видно - где это нужно: шифрование данных устройств на Android.
Сейчас это делается через ту самую "надстройку".
А про "не дело" - наверное, судить разработчику и компании, которая оплатила его труд, а не Вам?
Причём тут Android?
Что, Ext* нигде кроме как в Android не используется?>судить разработчику и компании, которая оплатила его труд, а не Вам?
При формировании своего мнения о каком-либо событии я не заглядываю в платёжные ведомости, штатные расписания и прочее. И вообще считаю эту информацию бесполезной при формировании своего мнения.
продолжайте информировать о своем мнении, оно очень важно для нас
Ты будешь ржать, но комментарии к статье предусмотрены именно для того, что люди выражали своё мнение. Так что сдуй щёки и засунь свой сарказм... обратно.
Что за ерунда? Комментарии предназначены для хамства и распространения заведомо ложных утверждений, почитай комментарии на opennet.
> Что, Ext* нигде кроме как в Android не используется?Поставим вопрос иначе: есть ли смысл использовать Ext* где-либо в принципе, если есть файловые системы лучше по всем релевантным параметрам?
Чиво?
> есть ли смысл использовать Ext* где-либо в принципе, если есть файловые системы лучше по всем релевантным параметрам?Если есть, то нет. А так - есть.
> Поставим вопрос иначе: есть ли смысл использовать Ext* где-либо в принципеExt4 - простой и быстрый. Если это все что надо от ФС - Ext4 вполне подходит. Он не требует гигантских ресурсов и шустро работает в большинстве типовых нагрузок.
> Причём тут Android?Новость ни читай, комментарии пиши быстрей давай?
Цитирую специально для не читающих:
> работающий в компании Google
> данные патчи войдут в состав следующего релиза Android "M".Совсем не причём, да?
И абсолютно понятно - для чего это:
http://habrahabr.ru/company/eset/blog/252027/
http://www.oszone.net/25728/Android_5_0_FDE_cause_performanc...
Откуда вас столько берётся, горе-комментаторов нечитающих...
> Совсем не причём, да?Совсем не причём. У меня корневая ФС на десктопной машине -- именно Ext*. Какая мне нахрен разница, какие патчи войдут в состав следующего релиза Андроида???
И если гражданин Шталь этажом выше сказал, что к нему Андроид никаким боком не относится, то вполне возможно, что так оно и есть.
Вас под палками заставляют пользоваться всеми функциями ФС? Уберете галочку о шифровании Ext4 и будете жить дальше. Я такую галочку поставлю, и буду жить с шифрованными папками без левого корявого софта
> Вас под палками заставляют пользоваться всеми функциями ФС? Уберете галочку о шифровании
> Ext4 и будете жить дальше. Я такую галочку поставлю, и буду
> жить с шифрованными папками без левого корявого софтаНет, не заставляют. Но, как юзер этой ФС, я интересуюсь её новыми фичами.
А компрессия? А в чём различие?
А снапшоты? А LVM? А передача данных по сети? :-)У человека представления о ФС времён DOS, не трогайте его.
компрессию и дедупликацию тоже нужно делать отдельными продуктами с переносимостью на уровне encfs
А вам не кажется, что делать дедупликацию без знания в каких физических блоках что находится довольно тяжело?
ага, на отдельных хостах, стоящих в соседнем помещении.
специально для "тепло-ламповости" этого.
Или хотя бы это должен быть отдельный слой, который может быть включён поверх любой FS. А так - костыль, иначе и не назвать. Хотя сама затея - правильная. Смартфон - это ПРИВАТНОЕ хранилище, практически продолжение головы. Он, по идее, вообще не должен быть рассчитан на доступ кого-либо кроме хозяина.
> Он, по идее, вообще не должен быть рассчитан на
> доступ кого-либо кроме хозяина.а также разработчиков ОС, разработчиков приложений, провайдеров сервисов, разработчков чипов, контрольных органов, органов контролирующих контрольных..
И права отрубить у пользователя на всякий случай.
А то ишь чего ещё задумал! Ключи ему разрешай в Secure boot добавлять! Ишь чего надумал..
А про root на android я вообще молчу.
"Ишь ты!" https://www.youtube.com/watch?v=BNkRSETRkaU&feature=youtu.be...
э-э.. сейчас уже таких не снимают :-)
Ты о чём, болезный? Какой Secure Boot на смартфоне?А так - ну да, есть разница между идеальным положением вещей и реальностью. Так что - предлагаешь лапки сложить и даже не думать, как должно бы быть по уму?
> Ты о чём, болезный? Какой Secure Boot на смартфоне?эт слова в тему, об общем положении вещей. Хотя, судя по тенденциям, скоро может быть и на смартфоне
> Так что - предлагаешь лапки сложить и даже не думать, как должно бы быть по уму?
Протри монитор, такого в посте не было.
(если не в курсе https://ru.wikipedia.org/wiki/%D0%A1%D0%...)
>> Ты о чём, болезный? Какой Secure Boot на смартфоне?
> эт слова в тему, об общем положении вещей. Хотя, судя по тенденциям,
> скоро может быть и на смартфонеА что его там уже отключили? Очень немногие девайсы не требуют разлочки загрузчика, чтобы прошить туда другую фирмварь. Чем это технически отличается от SecureBoot?
> Не дело это. Нечего шифрованию делать в коде ФС -- шифрование это не обязанность ФСА сжатие - обязанность ФС. Таки в чем великая разница между сжатием и шифрованием, когда на носителе физически лежат не те данные которые при чтении отдаются ?
Такшта вы или крестик оденьте или трусы сымите.
> Такшта вы или крестик оденьте или трусы сымите.Правильнее "Или крестик снимите или трусы оденьте"
А я вот не понял ваших доводов. ФС это такая черная коробка, на входе у которой данные для записи, а на выходе - ранее сохраненные данные. Что происходит с данными внутри - это дело черной коробки. Может исходя из каких-то особенностей физического носителя данные имеет смысл дробить, линчевать, добавлять дополнительную информацию для восстановления в случае частичной потери данных. А вы хотите запретить ФС делать это. Да кто вы такой? Есть интерфейс и предсказуемое поведение + удовлетворительные характеристики производительности - значит ФС годная. А то заладили, обязанность или не обязанность.
Полезно конечно, но почему не компрессию? Оно ж намного полезнее, потому что согласен с мнением, что шифровать правильнее всё блочное устройство.
Кстати интересно как код будет написан, может можно будет заменить функцию шифрования функцией сжатия… с небольшим допилом…
Да, туда бу компрессию и снапшоты и я бы послал btrfs :)
> Да, туда бу компрессию и снапшоты и я бы послал btrfs :)LVM?
>> Да, туда бу компрессию и снапшоты и я бы послал btrfs :)
> LVM?Сжатие?
Извращенцы создают ZFS пул и в нем создают ext4 o_O
Не такие уж и извращенцы. Словить dead-lock/панику на lvm - как 2 пальца, по моему довольно-таки богатому опыту совокупления со всякими виртуализаторами.
Пример: qcow-контейнер + quemu nbd. Глучный nbd валится - смонтированный с него lvm встаёт колом.
zpool как бы не постабильнее оказался, даже на linux...
последовательность команд можно , а то что-то не сильно понятно чем вы там lvm залочили
> последовательность команд можно , а то что-то не сильно понятно чем вы
> там lvm залочили1. Подключаем контейнер на nbd, внутри чсх lvm, с него монтируем том.
#modprobe nbd max_part=63
#qemu-nbd -c /dev/nbd0 /mnt/images/130/vm-130-disk-1.qcow2
nbd: registered device at major 43
nbd0: p1 p2 < p5 >2. Монтируем, что-то делаем (копируем файло), nbd рушится:
#mount /dev/nbd0p1 /nbd0/
#cd /nbd0/ && tar -cf www.tgz var/www/
EXT3-fs (nbd0p1): 5 orphan inodes deleted
EXT3-fs (nbd0p1): recovery complete
EXT3-fs (nbd0p1): mounted filesystem with ordered data mode
nbd (pid 117717: qemu-nbd) got signal 9УСЁ. Для системы это теперь "Buffer I/O error on device dm-3", со стороны lvm - любая операция _намертво_ блокируется попыткой прочитать из device mapper'а.
Данный пример дёрнул из debian 6.0.7 + proxmox.
>[оверквотинг удален]
> #mount /dev/nbd0p1 /nbd0/
> #cd /nbd0/ && tar -cf www.tgz var/www/
> EXT3-fs (nbd0p1): 5 orphan inodes deleted
> EXT3-fs (nbd0p1): recovery complete
> EXT3-fs (nbd0p1): mounted filesystem with ordered data mode
> nbd (pid 117717: qemu-nbd) got signal 9
> УСЁ. Для системы это теперь "Buffer I/O error on device dm-3", со
> стороны lvm - любая операция _намертво_ блокируется попыткой прочитать из device
> mapper'а.
> Данный пример дёрнул из debian 6.0.7 + proxmox.эмммм... proxmox использует сильно специфичное ядро
вот например debian wheeze + backport
# uname -srv
Linux 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt7-1~bpo70+1 (2015-04-07)
modprobe nbd max_part=63
qemu-nbd -c /dev/nbd0 test.img
fdisk /dev/nbd0
ls -la /dev/nbd0p1
brw-rw---T 1 root disk 43, 1 Apr 14 22:28 /dev/nbd0p1
mkfs.ext4 /dev/nbd0p1
mount /dev/nbd0p1 /mnt/
cd /mnt/
dd if=/dev/urandom of=/mnt/test.file bs=1k count=100
cat >>test.file <<EOF
печатаем либерду и одновременно kill -KILL на qemu-nbdEOF
-su: test.file: Read-only file systemdmesg
[10047.450190] nbd: registered device at major 43
[10091.031143] nbd0: unknown partition table
[10108.135157] nbd0: p1
[10130.033100] block nbd0: Other side returned error (22)
[10130.033112] end_request: I/O error, dev nbd0, sector 34816
[10152.637827] EXT4-fs (nbd0p1): mounted filesystem with ordered data mode. Opts: (null)
[10273.090016] nbd (pid 4693: qemu-nbd) got signal 9
[10273.090032] block nbd0: shutting down socket
[10273.090043] block nbd0: Receive control failed (result -4)
[10273.090148] block nbd0: queue cleared
[10274.763185] block nbd0: Attempted send on closed socket
[10274.763198] end_request: I/O error, dev nbd0, sector 61704
[10274.763242] block nbd0: Attempted send on closed socket
[10274.763247] end_request: I/O error, dev nbd0, sector 61960
[10274.763270] block nbd0: Attempted send on closed socket
[10274.763274] end_request: I/O error, dev nbd0, sector 62216
[10274.763296] block nbd0: Attempted send on closed socket
[10274.763299] end_request: I/O error, dev nbd0, sector 62472
[10274.763320] block nbd0: Attempted send on closed socket
[10274.763324] end_request: I/O error, dev nbd0, sector 62728
[10274.763345] block nbd0: Attempted send on closed socket
[10274.763349] end_request: I/O error, dev nbd0, sector 62984
[10274.763370] block nbd0: Attempted send on closed socket
[10274.763374] end_request: I/O error, dev nbd0, sector 63240
[10274.763395] block nbd0: Attempted send on closed socket
[10274.763398] end_request: I/O error, dev nbd0, sector 63496
[10274.763419] block nbd0: Attempted send on closed socket
[10274.763423] end_request: I/O error, dev nbd0, sector 63752
[10274.763444] block nbd0: Attempted send on closed socket
[10274.763448] end_request: I/O error, dev nbd0, sector 64008
[10274.763469] block nbd0: Attempted send on closed socket
[10274.763490] block nbd0: Attempted send on closed socket
[10274.763512] block nbd0: Attempted send on closed socket
[10274.763533] block nbd0: Attempted send on closed socket
[10274.763554] block nbd0: Attempted send on closed socket
[10274.763575] block nbd0: Attempted send on closed socket
[10280.100946] block nbd0: Attempted send on closed socket
[10280.100962] blk_update_request: 6 callbacks suppressed
[10280.100968] end_request: I/O error, dev nbd0, sector 3672472
[10280.100978] Aborting journal on device nbd0p1-8.
[10280.101001] block nbd0: Attempted send on closed socket
[10280.101005] end_request: I/O error, dev nbd0, sector 3672064
[10280.101011] Buffer I/O error on device nbd0p1, logical block 458752
[10280.101015] lost page write due to I/O error on nbd0p1
[10280.101041] JBD2: Error -5 detected when updating journal superblock for nbd0p1-8.
[10281.715909] block nbd0: Attempted send on closed socket
[10281.715920] end_request: I/O error, dev nbd0, sector 2048
[10281.715927] Buffer I/O error on device nbd0p1, logical block 0
[10281.715931] lost page write due to I/O error on nbd0p1
[10281.715966] EXT4-fs error (device nbd0p1): ext4_journal_check_start:56: Detected aborted journal
[10281.715973] EXT4-fs (nbd0p1): Remounting filesystem read-only
[10281.715978] EXT4-fs (nbd0p1): previous I/O error to superblock detected
[10281.715993] block nbd0: Attempted send on closed socket
[10281.715997] end_request: I/O error, dev nbd0, sector 2048
[10281.716001] Buffer I/O error on device nbd0p1, logical block 0
[10281.716005] lost page write due to I/O error on nbd0p1# pvs
/dev/nbd0p1: read failed after 0 of 4096 at 4293853184: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 4293910528: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 0: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 4096: Input/output error
PV VG Fmt Attr PSize PFree
/dev/sda5 *** lvm2 a-- 295.52g 4.08g
/dev/sdc3 *** lvm2 a-- 111.82g 0
/dev/sdc5 *** lvm2 a-- 52.52g 1.37g
# lvs
/dev/nbd0p1: read failed after 0 of 4096 at 4293853184: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 4293910528: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 0: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 4096: Input/output error
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
*** *** -wi-ao-- 136.97g
*** *** -wi-a--- 14.00g
*** *** -wi-ao-- 12.00g
*** *** -wi-ao-- 281.43g
*** *** -wi-ao-- 10.00g
# lvcreate -n asd -L 4M ***
mkfs.ext4 /dev/mapper/***-asd
mkdir /tmp/asd
mount /dev/mapper/***-asd /tmp/asd/
cd /tmp/asd
echo 1> test.file
cd -
umount /tmp/asd/
lvremove /dev/***/asd
/dev/nbd0p1: read failed after 0 of 4096 at 4293853184: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 4293910528: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 0: Input/output error
/dev/nbd0p1: read failed after 0 of 4096 at 4096: Input/output error
Do you really want to remove active logical volume asd? [y/n]: y
Logical volume "asd" successfully removed
qemu-nbd -c /dev/nbd0 test.img
mount -o remount,rw /mnt/
mount: cannot remount block device /dev/nbd0p1 read-write, is write-protected
# blockdev --setrw /dev/nbd0
# blockdev --setrw /dev/nbd0p1
# mount -o remount,rw /mnt/
mount: cannot remount block device /dev/nbd0p1 read-write, is write-protectedчто собственно логично.
НО никакого лока на nbd у lvm нет, или нет уже, а то ядро которое идёт с proxmox'ом оставляет много лучшего, как и сама система (proxmox) в целом. (чего только стоит распад кластера при недоступности удалённой fs (например nfs))
> [10273.090016] nbd (pid 4693: qemu-nbd) got signal 9Как в анекдоте, "я 'рад, что по предыдущему вопросу у Вас воз'ражений нет".
(nbd до сих пор валится)
Ну а что lvm постепенно допиливают - оно не может не радовать. Те же thin volumes и т.п. постепенно перестают быть рисковыми технологиями.
Правда, у zpool пока остаётся киллер-фича в виде репликации журналов. У lvm видел на эту тему чью-то ученическую поделку, и только.* Проблема в данном раскладе не столько в proxmox'е (хотя гуано, согласен, но работать сплошь и рядом приходится с тем, что какой-нибудь пионер вклячил до тебя), сколько в старых ядрах. На rhel'5x-образных ещё и паника ловилась тупо при дёргании снапшотов.
>> [10273.090016] nbd (pid 4693: qemu-nbd) got signal 9
> Как в анекдоте, "я 'рад, что по предыдущему вопросу у
> Вас воз'ражений нет".
> (nbd до сих пор валится)kill -KILL не о чём не говорит? или таки пейсатель?
> Ну а что lvm постепенно допиливают - оно не может
> не радовать. Те же thin volumes и т.п. постепенно перестают быть
> рисковыми технологиями.
> Правда, у zpool пока остаётся киллер-фича в виде репликации журналов.
> У lvm видел на эту тему чью-то ученическую поделку, и только.а вы из этих...
> * Проблема в данном раскладе не столько в proxmox'е (хотя гуано, согласен,
> но работать сплошь и рядом приходится с тем, что какой-нибудь пионер
> вклячил до тебя), сколько в старых ядрах. На rhel'5x-образных ещё и
> паника ловилась тупо при дёргании снапшотов.
> kill -KILL не о чём не говорит? или таки пейсатель?Ну извините. Я по Вашей простыне наискось пробежался. Свою, заметьте, не поленился отфильтровать.
>> У lvm видел на эту тему чью-то ученическую поделку, и только.
> а вы из этих...Из инженеров, собирающих заказанный продукт из имеющегося, ага.
Специально для эстетов, нашёл: https://github.com/mpalmer/lvmsync
Оно развивается и вполне разумно задумано, но ruby в данном секторе лично мне доставляет.Там ещё есть ссылка на реально ученическую работу blocksync.py - оно изначально КС по блокам считало через adler32 https://gist.github.com/rcoup/1338263/revisions. Теперь автор повзрослел и поправил на sha /а современный rsync до сих пор md4 считает afaik/.
Мда. Когда я обнаружил эту питонятину в одном довольно таки серьёзном проекте, получил неслабый заряд позитива. А отсмеявшись, воткнул на его место патченный rsync, который btw тоже не фонтан. Но уж что было...
>> kill -KILL не о чём не говорит? или таки пейсатель?
> Ну извините. Я по Вашей простыне наискось пробежался. Свою, заметьте,
> не поленился отфильтровать.я и говорю не читатель, потому что моя простыня не большая это раз, а два это то что необходимое вам в подтверждение вы нашли быстро, а из этих вы потому что инженер в первую очередь пошел-бы искать причины падения вполне-себе userspace-ного сервиса по сигналу KILL, что делается в Linux давольно просто. Вместо поиска проблем с nbd вы стали лечить и жаловаться на симптомы (lvm).
>>> У lvm видел на эту тему чью-то ученическую поделку, и только.
>> а вы из этих...
> Из инженеров, собирающих заказанный продукт из имеющегося, ага.инженер из говна конфету не лепит -- для этого есть другие люди.
>[оверквотинг удален]
> Оно развивается и вполне разумно задумано, но ruby в данном секторе лично
> мне доставляет.
> Там ещё есть ссылка на реально ученическую работу blocksync.py -
> оно изначально КС по блокам считало через adler32 https://gist.github.com/rcoup/1338263/revisions.
> Теперь автор повзрослел и поправил на sha /а современный rsync до
> сих пор md4 считает afaik/.
> Мда. Когда я обнаружил эту питонятину в одном довольно таки
> серьёзном проекте, получил неслабый заряд позитива. А отсмеявшись, воткнул на его
> место патченный rsync, который btw тоже не фонтан. Но уж что
> было...мне эта тема неинтересна - я не вижу где подобные техники можно применить (особенно если это делается как в приведённых примерах), но для для того чтобы иметь возможность копировать изменённые блоки с lv давно есть dm-era https://github.com/jthornber/thin-provisioning-tools
в частности у разрабов всевозможных утилит архивирования данная техника может быть применена по алгоритму
1. получаем изменённые блоки
2. через lib2fs/debug2fs получаем имя файла/ов находящегося в данном блоке
3. проводим синхронизацию.
> Извращенцы создают ZFS пул и в нем создают ext4 o_Oada0 <-> GEOM ELI <-> zpool <-> ZVOL (с установленным свойством сжатия LZ4) <-> ext4 чем не вариант для бедных линуксоидов, озабоченных проблемой шифрования и сжатия данных на ФС, которая не поддерживает ни того, ни другого?
Как не пили ext4 он неисправим!
толсто
>>> Да, туда бу компрессию и снапшоты и я бы послал btrfs :)
>> LVM?
> Сжатие?Были падчи для ext2 и ext3 с потдержкой сжатия - до версии ядра 2.6.6 входили в ядра от
Zen-kernel и Кона Коливаса ,из за невостребованости потдержка прекращена :-(Проект Next3 - ext3/4 с снапшотами ,обновлений нет 3 года Ж-(
Проект ext3cow -ext3 c снапшотами ,обновлений нет уже 7 лет ...
Правильнее-то правильнее.
Но есть шанс, что при выборе "Допилить аппаратный загрузчик для поддержки полного шифрования девайса" и "ничего не делать, оставить всё как сейчас" большинство Андроидных вендоров предпочтёт последнее.А тут есть возможность иметь промежуточный вариант, включаемый по желанию пользователя и сочетающий систему-как-всегда и зашифрованные пользовательские данные, возможно даже — в пределах одного и того же раздела.
А кто-то сказал, что _пользователю_ дадут шифровать данные?
Компрессия уже в ssd и если её и развивать то уж проще в устройствах.
> шифровать правильнее всё блочное устройствоПравильнее для чего? Я лично вижу много пользовательских проблем: забыли защитить файл и т.д. А в остальном только плюсы.
> Ключ шифрования определяется во время монтирования ФС
Плохо что не при первом обращении. Получается опять монтирование и запрос пароля для home при входе в систему.
Лучше поздно, чем никогда.
> Реализация подразумевает предоставление возможности шифрования отдельных частей ФС.
> Ключ шифрования определяется во время монтирования ФС.т.е. зашифровать с разными ключами разные директории не получится.
Ну и ZSTD сжатие тогда уж можно было запилить, зачем мелочиться?
а юзер вася сможет, не имея прав админа, зашифровать файлы в своей домашней директории (на подобии виндовс)?
> а юзер вася сможет, не имея прав админа, зашифровать файлы в своей
> домашней директории (на подобии виндовс)?В рамках данной технологии нет. Ибо ключ определяется на моменте монтирования, а отмонтировать сам себе хомяк юзер не сможет.
А сделать флешку с шифрованием, наверное, сможет, т.к. монтировать права у него будут.
Метаданные не шифруются, чтобы полиция видела факт наличия файла и при желании смогла нагнуть юзера. Получается, для простых людей данные недоступны, а для силовых структур - доступны. И овцы целы, волки сыты.
Давай, у меня есть директория, в которой пара тысяч файлов с ннеодинаковыми именами и зашифрованным содержимым. Ты можешь прочитать права и время доступа к ним.Нагни меня! Нагни меня полностью!
Когда тебя ТАМ станут нагибать, главное, что-бы кто-то ещё хотел тебя слушать, как ты будешь верещать, что сейчас сейчас, я всё вам расшифрую. Потому что, если всем будет уже пофигу, то твоё дело - совсем дрянь.
>Нагни меня! Нагни меня полностью!Я медленно подключаю свой большой паяльник к сети и он начинает нагреваться... Всё жарче и жарче...
> При этом шифруется только содержимое и имена файловИтого спецслужбы увидят, что 8-го марта был создан какой-то файлик размером 10 килобайт. А что это - поздравление любимой или код запуска ракет - они не увидят.
Ещё они увидят, что "поздравление любимой" зашифровано.
> зашифрованоПоздравляю любимая/любимый!
И да, не забудь купить рулона 4 туалетной бумаги, пачку (на 250 грамм) масла ... <далее, на что хватит фантазии - за классику типа "книжка, страница, строка" я уж молчу>
И помни! Одинадцатого, рейсом в 12:10, прилетает твоя тетя Оба-на, ее нужно забрать!
Смотри, забудешь - будешь успокаивать сам!
Лучше б продвинули сжатие на лету
Да что вы все так жать рвётесь? Объемных данных есть, грубо говоря, всего два варианта - разного рода BigData, где движки при нужде со сжатием сами прекрасно разобраться могут, а вот лишний слой с непредстказуемыми характеристиками - только ко вред, и мультимедиа-данные, которые толком жмутся только специфическими алгоритмами. Да и в остальных областях где было нужно и возможно - вплоть до паршивых офисных документов - сжатие уже в комплекте.
>> Предполагается что данные патчи войдут в состав следующего релиза Android "M"а в ванильном ядре будет?
А производительность? В ядре под ARM заточен только AES и SHA1. Да и отсутствие альтернативы настораживает.
А так да, идея весьма не плохая