Microsoft опублікувала інформацію про реалізації VFS в підсистемі Linux на Windows 10

В попередніх постах ми висвітлювали деякі елементи реалізації підсистеми Linux Windows 10 (WSL). При цьому мова йшла про механізми імплементації системних сервісів Linux на основі системних модулів Windows 10. Ми вказували, що такі як драйвери LXss.sys і LXCore.sys відповідають за реалізацію семантики системних викликів Linux з використанням ядра Windows. У разі збігу семантики системного сервісу Linux і Windows, вищезазначені драйвери просто перенаправляють системний виклик Linux відповідний еквівалент Windows.



У цьому пості мова піде про реалізації віртуальної файлової системи VFS в WSL, яка використовується як рівень абстракції в Linux при доступі як до дискових файлів, так і інших об'єктах ОС, включаючи, пристрої, порти, процеси, мікропроцесор і т. д. Так як ядро Windows 10 має структуру підсистем і спочатку розраховане на реалізацію різних типів оточення, включаючи POSIX, що відповідає за семантику VFS драйвер LXCore.sys звертається до цих підсистем ядра, реалізуючи відповідну семантику та директорії типу /dev, /proc, /sys.


Рис. Загальна схема реалізації VFS в WSL. На верхньому рівні знаходяться додатки Linux, які викликають API ОС, відповідає за їх реалізацію драйвер режиму ядра LXCore.sys. Для реалізації семантики VFS драйвер звертається до різним підсистемам ядра Windows, включаючи, диспетчер об'єктів (ObMgr) для роботи з системою імен Windows і простором імен диспетчера об'єктів, диспетчер введення/виводу (IoMgr) для реалізації директорії типу /dev, а також драйвер файлової системи NTFS для роботи з дисковими файлами.

WSL обепечивает додатки Linux необхідної семантикою VFS, при цьому виконується підтримка системи дозволів (permissions) файлів і директорій, символьних посилань, спеціальних файлів типу FIFO, а також вищезазначених директорій /dev, /proc, /sys і ін. Коли програма викликає одну з функцій типу open, read, chmod, stat, відповідний системний виклик береться за її обробку і передає управління шару реалізації VFS (LXCore.sys). Далі, при обробці шляхів файлів (наприклад, при виконанні функцій open stat), VFS перетворює його у внутрішній формат з використанням спеціального кеш (cache directory entry). У разі відсутності потрібного елемента шляху в кеші, здійснюється виклик одного або кількох спеціальних плагінів (див. нижче) для створення відомої структури inode цього елемента. Ця структура буде представляти відкритий додатком файл в WSL.

Windows не має структури типу inode для подання дескриптор відкритого файлу, замість цього використовується відома структура під назвою file object, яка зберігає деяку інформацію про файлі (розмір, атрибути, маска доступу тощо). На неї внутрішньо і спирається LXCore.sys при реалізації inode. Однак, і Linux і Windows використовують файлові дескриптори для подання відкритого файлу, деталі роботи з якими приховує LXCore.sys. Він визначає рівні так званих плагінів під назвами VolFs і DrvFs, які відповідають за роботу з дисковими файлами, TmpFs для роботи з даними файлової системи в пам'яті (in-memory file system), а також псевдо-ФС ProcFs, SysFs, і CgroupFs.

VolFs

Плагін VolFs використовується VFS для роботи з дисковою файловою системою, він використовується для зберігання системних файлів Linux, а також вмісту директорії /home. VolFs підтримує роботу з дозволами файлів Linux, символьними посиланнями, сокетами, файлами пристроїв, а також FIFO. Монтування директорій /root /home здійснюється в директорії %LocalAppData%\lxss\root і %LocalAppData%\lxss\home. При видаленні підсистеми WSL збережені в цих директоріях файли не видаляються. Як видно з шляху, директорії монтування каталогів Linux залежать від конкретного користувача, тобто кожен користувач Windows має свою директорії WSL. Тому, установка додатків Linux WSL одним користувачем не торкнеться інших.

WSL забезпечує додатки двома особливостями файлової системи Linux, підтримка яких відсутня у Windows безпосередньо. Першою такою особливістю є чутливість ФС до регістра імен файлів, в такому випадку VolFs просто звертається до диспетчера об'єктів, вказуючи певний прапор для проведення операції. Так як NTFS внутрішньо розрізняє регістр імен файлів, реалізація цієї особливості є досить простим завданням.

Другою особливістю є підтримка майже всіх можливих символів в якості застосовних до назв файлів. Windows має більш суворі обмеження на назви файлів, при цьому деякі символи в іменах файлів є неприпустимими, а інші можуть мати особливе значення, наприклад, символ двокрапки ":", що позначає альтернативний потік даних у файлі. При реалізації цієї особливості, VolFS уникає використання неприпустимих символів у назвах.

Структури inode в Linux мають ряд атрибутів, які відсутні в Windows, включаючи відомості про власника й групі, а також режим (mode). Ці атрибути зберігаються в структурі розширених атрибутів NTFS Ea, які асоційовані з файлами на диску. У цьому атрибуті файлу NTFS Ea зберігається наступна інформація:

  • Режим файлу (mode): включає в себе тип файлу (звичайний, символьне посилання, FIFO, тощо), а також біти дозволів для файлу.
  • Інформація про власника: код групи і користувача власників файлу.
  • Device ID: для файлів, які представляють пристрої, старший і молодший номери пристроїв. Поки WSL не дозволяє користувачам створювати файли пристроїв на VolFS.
  • Тимчасові мітки файлу: тимчасові мітки останнього доступу до файлу та його модифікації. В Linux використовується інший формат тимчасових міток, тому інформація про них зберігається в розширених атрибутах.
DrvFs

Для полегшення взаємодії з Windows, WLS використовує плагін DrvFs. WSL автоматично монтує всі дискові пристрої з підтримуваними файловими системами в каталог /mnt, наприклад, /mnt/c, /mnt/d. На поточний момент підтримуються тома з файловими системами NTFS і ReFS. DrvFs працює таким же чином, що і VolFs. При відкритті потоком файлового дескриптора, створюються структури file object і inode. Тим не менш, на відміну від VolFs, DrvFs дотримується правил Windows при роботі з файловою системою. Він використовує дозволу для файлів Windows, тільки легальні назви файлів NTFS, при цьому такі спеціальні файли як FIFO і сокети не можна.

Відомо, що Linux використовує досить просту модель дозволів, коли власнику файлу, групи або кому-небудь ще дозволяється виконувати його, читати або записувати дані. У Windows використовується більш складна модель на основі списків керування доступом (Access Control List (ACL), які визначають складні правила доступу для кожного окремого файлу або директорії (Linux також володіє можливістю підтримки ACL, але на даний момент ця функція не підтримується WSL).

Коли відбувається відкриття файлу через плагін DrvFs, він використовує механізм дозволів Windows, заснований на маркері доступу користувача, у контексті якого був запущений процес командного інтерпретатора bash.exe. Таким чином, для отримання доступу до файлів в системній директорії C:\Windows недостатньо просто використовувати команду sudo, яка може надати права root в WSL. Остання не змінює маркер доступу процесу, тому для виконання зазначеної операції слід запустити додаток bash з підвищеними привілеями в Windows.

WSL може дати користувачеві підказку про ті дозволи, які він має при доступі до файлів, при цьому DrvFs перевіряє чинні дозволи користувача і конвертує їх в біти read/write/execute, які можна побачити при виконанні команди «ls -l». Однак, не завжди існує можливість прямого перетворення; наприклад, у Windows є окремі дозволи на можливість створення файлів та підкаталогів в директорії. У випадку присутності у користувача таких дозволів, DrvFs вкаже йому на присутність write-доступу до директорії, в той час як деякі операції з нею для нього можуть бути недоступні.

Оскільки зазначений WLS доступ до файлу може відрізнятися, залежно від того, якими правами володіє запущений в Windows процес bash.exe, вказані дозволи на доступ до файлів будуть змінюватися при перемиканнями між копіями bash.exe з різними правами (один запущений від простого користувача, а другий від адміністратора). При розрахунку дозволів на доступ до файлу, DrvFs бере до уваги атрибут read-only. Файл з атрибутом " read-only буде відображатися в WSL як не має дозволу на запис. Команда chmod може бути використана для установки атрибута read-only (шляхом видалення всіх дозволів на запис, тобто chmod a-w some_file) або видалення його (установкою будь-якого дозволу на запис, тобто chmod u+w some_file). Така поведінка WSL схоже з файловою системою CIFS в Linux, яка використовується при доступі до загальних ресурсів Windows SMB.

На відміну від VolFs, DrvFs не зберігає жодної додаткової інформації про файли. Замість цього, всі атрибути inode формуються на основі інформації, яка використовується в Windows, шляхом запиту діючих атрибутів файлів, чинних дозволів та іншої інформації. DrvFs також забороняє використання спеціального кешу каталогів (directory entry cache). Це робиться для постійного підтримання в стані актуальності, навіть в тому випадку, коли один з інших процесів Windows модифікує вміст директорії. Таким чином, не існує обмежень на те, що процеси Windows можуть робити з файлами, поки DrvFs також має до них доступ. DrvFs також використовує семантику Windows при видаленні файлів, так що над файлом не може бути здійснена операція unlink у разі присутності будь-яких відкритих дескрипторів на нього.

ProcFs і SysFs

У випадку з Linux дані типи спеціальних директорій не працюють з дисковими файлами, натомість надаючи інформацію, яка є у ядра ОС про запущених процесах, потоках, пристроях. Ці директорії динамічно генеруються при спробі їх читання клієнтом. В деяких випадках, інформація для цих директорій цілком зберігається в пам'яті LXCore.sys. В інших випадках, наприклад, використання мікропроцесора яким-небудь з процесів, WSL запитує цю інформацію у ядра Windows. Однак, в обох випадках плагіни не взаємодіють з дисковими файловими системами Windows.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.