Как смонтировать NFS на Android с правильными разрешениями?

Я пытаюсь смонтировать общий ресурс NFS на своем телефоне Android.

Я уже скомпилировал и установил все необходимые модули ядра. Общий ресурс NFS монтируется безупречно, но я могу подключиться только как пользователь system . Это не было бы проблемой, если бы я мог правильно установить владельца для смонтированной файловой системы. Проблема в том, что общий ресурс всегда монтируется как user = system и group = system , что делает его недоступным для обычных приложений.

Я хотел бы иметь возможность указать владельца смонтированной файловой системы во время монтирования.

Вот как я монтирую общий ресурс NFS

  su -c "busybox mount -o nosuid, nolock, nodev, rw, nofail, noatime, intr, tcp, actimeo = 1800, context = u: object_r: rootfs: s0, user -  t nfs $ REMOTE_URI $ LOCAL_DIRECTORY " 

где REMOTE_URI – удаленное расположение, а LOCAL_DIRECTORY – локальный каталог . Вышеупомянутая команда находится внутри сценария.

Это соответствующая строка файла /etc/exports на сервере NFS (raspberry pi 3)

 /media/neo/BLACKBOX XXX.XXX.XXX.XXX/0(rw,insecure,sync,no_root_squash,no_subtree_check,anonuid=1000,anongid=1000)   

Системные характеристики:

• LG V20 H990DS
• Система – V10i -TWN (6 ноября, 17) 7.0 Stock, root и Xposed
• Ядро – DOTS v1.4
• NFS версии 4

PS: UID и GID на сервере – 1000 и 1000 соответственно. В Android они зарезервированы для системного пользователя и группы. Все мои другие компьютеры имеют UID и GID 1000 и то же имя пользователя neo . Было бы намного проще просто изменить способ монтирования общего ресурса Android. Я хотел бы сопоставить uid = neo (1000) -> root (0) и guid = neo (1000) -> sdcard_r (1028) , где neo: neo – это пользователь на сервере, а root: sdcard_r – это пользователь на телефоне.

  ~ # exportfs -o rw, insecure, no_subtree_check, anonuid = 1000, anongid = 1000, sec = none, root_squash, all_squash : /SHARED_DIR ~ # chown -R 1000.1000/SHARED_DIR;  chmod 0700/SHARED_SIR  

  ~ # busybox mount -v -t nfs4 -o  vers = 4.2, sec = none, rw, tcp, port = 2049, context = u: object_r: sdcardfs: s0 :/SHARED_DIR/mnt/runtime/write/emulated/0/NFS  

  ~ # mkdir -p/mnt/NFS/sdcard/NFS ~ # busybox  mount -v -t nfs4 -o vers = 4.2, sec = none, rw, tcp, port = 2049, context = u: object_r: sdcardfs: s0 :/SHARED_DIR/mnt/NFS ~ # mount -t sdcardfs -  o nosuid, nodev, noexec, noatime, mask = 7, gid = 9997/mnt/NFS/mnt/runtime/write/emulated/0/NFS  

  ~ # bindfs -o nosuid, nodev, noexec, noatime, context = u: object_r: fuse: s0 -u  0 -g 9997 -p a-rwx, ug + rw, ugo + X --xattr-none --chown-ignore --chgrp-ignore --chmod-ignore/mnt/NFS/mnt/runtime/write/emulated/ 0/NFS  

  ~ # mkdir -p/sdcard/CIFS ~ # busybox mount  -v -t cifs -o vers = 3.0, nosuid, nodev, noexec, noatime, rw, hard, context = u: object_r: sdcardfs: s0, nounix, uid = 0, gid = 9997, file_mode = 0660, dir_mode = 0770  , nouser_xattr, port = 445, username = USERNAME, password = PASSWORD///SHARED_DIR/mnt/runtime/write/emulated/0/CIFS  

Я хотел бы сопоставить uid = neo (1000) -> root (0) и guid = neo (1000 ) -> sdcard_r (1028) где neo: neo – это пользователь на сервере, а root: sdcard_r – это пользователь на телефоне.

Владение файлами root: sdcard_r (0: 1028) на Android не работает для приложений. Это должно быть root: everybody (0: 9997) с режимом 0770 для каталогов и 0660 для файлов.

КАК Заставить NFS РАБОТАТЬ С ПРИЛОЖЕНИЯМИ ANDROID?

Традиционный * NIX DAC (UID/GID) был разработан для изоляции пользователей-людей, не программы. На устройствах Android – обычно предназначенных для одного человека-пользователя – приложения должны быть изолированы и защищены, чтобы они не могли получить доступ к данным друг друга. Таким образом, Android рассматривает каждое приложение как человека-пользователя – с уникальным UID/GID.

Внешнее хранилище (/sdcard ) – физически внешнее или внутреннее – подразумевается будет использоваться всеми приложениями, то есть несколькими UID. Если это традиционная файловая система * NIX (например, ext4 ), каждое приложение будет создавать файлы со своим собственным UID/GID, что делает практически невозможным обмен файлами между всеми приложениями с доступом для чтения/записи. Чтобы предложить решение, Android выбрал эмулируемую файловую систему на основе FUSE или sdcardfs с фиксированным владельцем и режимом. См. Подробности в разделе Что такое UID «u # _everybody»?

Эти UID/GID и режимы также управляют доступом приложений к файлам в /sdcard . Поэтому, если мы хотим смонтировать NFS, чтобы он был доступен для всех приложений, нам необходимо уменьшить эти разрешения в соответствии с дизайном хранилища Android.

ОБЫЧНАЯ БЕЗОПАСНОСТЬ UNIX НА NFS:

В режиме sec = sys требуются разрешения UNIX без перевода. Как объяснялось в предыдущем разделе, файлы будут создаваться со случайным владением разными приложениями. Таким образом, они должны быть доступны для чтения/записи всем ( o + rw ), иначе приложения не смогут читать/писать. Но нет возможности принудительно включить режим создания файлов глобально, равно как и делиться файлами со слишком открытыми разрешениями. Возможное решение – использовать сопоставление идентификаторов и/или анонимный режим.

NFSv4 ID MAPPING:

С NFSv4 можно сопоставить различные UID/GID между клиентом и сервером . Если с обеих сторон существует пользователь с одинаковым именем, но с разными UID/GID, файлы на клиенте выглядят принадлежащими одному и тому же пользователю, а не одному и тому же UID. Средство управления ключами Linux ^* используется для хранения сопоставлений идентификаторов удаленных пользователей с идентификаторами локальных пользователей. Здесь можно найти хорошее объяснение.

Итак, идея состоит в том, чтобы создать user: group neo: neo на сервере NFS ( 1000 : 1000 ) и на Android ( 0 : 9997 ). Для этого rpc.idmapd должен быть запущен как на сервере, так и на клиенте, который запрашивает базу данных пользователей (в простейшем случае /etc/{passwd, group} ) через NSS. В более поздних ядрах клиент NFSv4 вместо этого использует nfsidmap и возвращается к rpc.idmapd только в том случае, если возникла проблема с запуском nfsidmap . Ядро вызывает двоичный файл /sbin/request-key в пространстве пользователя, который выполняет nfsidmap для запроса базы данных пользователей. Таким образом, ядро ​​будет отображать серверный neo ( 1000 : 1000 ) с клиентским neo ( 0 : 9997 ).

В простом случае, если диапазон UID/GID от 10000 до 19999 не назначен любой пользователь/группа на сервере NFS и Nobody-User = root / Nobody-Group = everybody определены в /etc/idmapd. conf на клиенте, все файлы (созданные приложениями Android), принадлежащие несуществующим пользователям на сервере, будут возвращены как принадлежащие 0 : 9997 на клиенте. Но это не решает проблему случайного владения файлами на сервере.

Запуск rpc.idmapd или предоставление nfsidmap на Android – сложная задача (статические ссылки и все такое). Однако – используя keyutils ( request-key и keyctl ) – мы можем обмануть ядро, чтобы показать фиксированное владение 0: 9997 для всех сопоставлений независимо от фактического владения:

На сервере NFS:

1. Запустить службы:

     ~ # mount -t nfsd nfsd/proc/fs/nfsd ~ # rpc.mountd -g  -N2 -N3 -N4 -N4.1 -N4.2 -p 4000 ~ # rpc.nfsd -N2 -N3 -N4 -N4.1 -N4.2 -U --p 2049 4 ~ # mkdir -p/run /rpc_pipefs ~ # mount -t rpc_pipefs sunrpc/run/rpc_pipefs ~ # rpc.idmapd -S -p/run/rpc_pipefs ~ # echo -n N>/sys/module/nfsd/parameters/nfs4_disable_idmapping ~ # export,  insecure, hide, no_subtree_check, sec = sys :/SHARED_DIR 

   Или настройте и запустите необходимые службы init . Также разблокируйте порты через брандмауэр на клиенте и сервере.

На Android:

1. Создать /sbin/nfsidmap_pseudo и /etc/request-key.conf :

     #!/system/ bin/shuid = 0gid = 9997case $ 2 in uid: *) printf '% s  0' "$ uid" | /sbin/keyctl установить $ 1 0 ;;  gid: *) printf '% s  0' "$ gid" | /sbin/keyctl установить $ 1 0 ;;  *) # ничего не сделает с типами "пользователь" или "группа" exit 1 ;; esac  

     #/etc/request-key.confcreate id_resolver  * */sbin/nfsidmap_pseudo% k% d  

2. Поместите файлы, установите разрешения и включите сопоставление идентификаторов ::

     ~ # chmod 0755/sbin/request-key/sbin/nfsidmap_pseudo/sbin/keyctl ~ # chmod 0644/etc/request-key.conf~# chown 0.0/sbin/request-key/sbin/ nfsidmap_pseudo/sbin/keyctl/etc/request-key.conf~# chcon u: object_r: rootfs: s0/sbin/request-key/sbin/nfsidmap_pseudo/sbin/keyctl ~ # chcon u: object_r: system_file: s0/etc/ request-key.conf ~ # echo -n N>/sys/module/nfs/parameters/nfs4_disable_idmapping  

3. Поскольку NFS не поддерживается официально в Android политика SELinux не имеет обязательных правил. Вам может потребоваться установить разрешающий режим SELinux или разрешить ядру читать/писать ключи, выполнять файлы в пользовательском пространстве и устанавливать соединения:

     ~ # supolicy --live 'allow kernel key {  search write view read} '~ # supolicy --live' разрешить возможности ядра {net_raw net_bind_service sys_admin} '~ # supolicy --live' разрешить ядро ​​{rootfs shell_exec system_file} файл {execute_no_trans выполнить open getattr} ' 

4. Монтировать:

     ~ # mkdir -p/sdcard/NFS ~ # busybox mount -v -t  nfs4 -o vers = 4.2, sec = sys, rw, tcp, port = 2049, context = u: object_r: sdcardfs: s0 :/SHARED_DIR/mnt/runtime/write/emulated/0/NFS   

К сожалению, из всей этой настройки мы получаем, что теперь приложения, по-видимому, видят файлы в /sdcard/NFS , принадлежащие 0: 9997 . Но с безопасностью sec = sys фактический доступ к файлам не регулируется сопоставлением UID NFSv4 ^** . Разрешения применяются механизмом RPC, который еще не готов работать с сопоставлением идентификаторов. Таким образом, сопоставление UID без защиты Kerberos работает только в том случае, если имя пользователя/группы и числовые пробелы согласованы между клиентом и сервером. Это означает, что пользователь neo на сервере должен иметь UID/GID: 0 / 9997 (что сводит на нет всю цель Сопоставление идентификаторов). С другой стороны, безопасность Kerberos ( sec = krb5 ) слишком беспокойна, чтобы ее можно было попробовать на Android.

Аналогичным образом для блокировки файлов в NFSv2/3 требуется portmapper ( rpcbind ) и rpc.statd , запущенные как на сервере, так и на клиенте, чего нельзя сказать о клиенте Android. Итак, нам нужно использовать параметр монтирования nolock . Однако в NFSv4 блокировка встроена в протокол NFS, NLM не требуется.. Так что лучше не использовать сопоставление UID (в NFSv4 и File Locking в NFSv2/3). Если вам нужны все функции NFS (включая Kerberos), работающие на устройстве Android, попробуйте небольшой дистрибутив Linux в chroot .

^{* В ядре старше v4.6, /proc/keys отображается, если ядро ​​построено с использованием KEYS_DEBUG_PROC_KEYS .
** Ссылки: 1, 2, 3, 4, 5, 6}

АНОНИМНЫЙ ДОСТУП к NFS:

Одним из вариантов безопасности NFS является анонимный режим . Каждый запрос от любого UID/GID на клиенте рассматривается как анонимный UID/GID на сервере. Первоначально все файлы в общем каталоге должны принадлежать этому UID/GID, и все впоследствии созданные файлы на стороне клиента также будут иметь такое же право собственности:

Экспорт общего ресурса с sec = none на сервере:

  ~ # exportfs -o rw, insecure, no_subtree_check, anonuid = 1000, anongid = 1000, sec = none, root_squash, all_squash : /SHARED_DIR ~ # chown -R 1000.1000/SHARED_DIR;  chmod 0700/SHARED_SIR  

^{* Для NFSv2/3 также запустите rpcbind (по умолчанию порт 111)}

Смонтировать с помощью sec = none На Android:

  ~ # busybox mount -v -t nfs4 -o  vers = 4.2, sec = none, rw, tcp, port = 2049, context = u: object_r: sdcardfs: s0 :/SHARED_DIR/mnt/runtime/write/emulated/0/NFS  

<sup>* Используйте -t и vers = в соответствии с конфигурацией сборки вашего ядра CONFIG_NFS_V [2 | 3 | 4 | 4_1 | 4_2] .
* Используйте -t nfs -o nolock с vers = 3 или vers = 2 .
* Убедитесь, что вы монтируете из корневого пространства имен монтирования.
* Монтирование с помощью sec = none не работает не работает с NFSv3.</sup>

Все приложения на Android теперь могут читать и записывать в каталог NFS, и все файлы создаются с одним анонимным UID/GID на сервере, которым легко управлять с помощью пользователь. Однако очевидное право собственности (если сопоставление идентификаторов не настроено) и режим разрешений не соответствуют особенностям Android, поэтому …

ПОПРОБУЙТЕ ПУТЬ ДЛЯ ANDROID …

Давайте использовать FUSE или sdcardfs , как это делает Android:

  ~ # mkdir -p/mnt/NFS/sdcard/NFS ~ # busybox  mount -v -t nfs4 -o vers = 4.2, sec = none, rw, tcp, port = 2049, context = u: object_r: sdcardfs: s0 :/SHARED_DIR/mnt/NFS ~ # mount -t sdcardfs -  o nosuid, nodev, noexec, noatime, mask = 7, gid = 9997/mnt/NFS/mnt/runtime/write/emulated/0/NFS  

Если ваше устройство не t поддерживает sdcardfs , используйте bindfs и замените контекст SELinux u: object_r: sdcardfs: s0 на u: object_r: fuse: s0 :

  ~ # bindfs -o nosuid, nodev, noexec, noatime, context = u: object_r: fuse: s0 -u  0 -g 9997 -p a-rwx, ug + rw, ugo + X --xattr-none --chown-ignore --chgrp-ignore --chmod-ignore/mnt/NFS/mnt/runtime/write/emulated/ 0/NFS  

Это не оставляет нам проблем. Для получения дополнительной информации см. Как привязать монтирование папки внутри/SDCard с правильными разрешениями?

ДАЙТЕ CIFS ШАНС …

NFS является собственной файловой системой Linux (например, ext4 ) предназначен для обеспечения * разрешений NIX. Ненативные файловые системы, такие как FAT и CIFS, позволяют устанавливать фиксированные права собственности и разрешения для всей файловой системы. Итак, то, что вы ищете, относительно легко сделать с помощью CIFS :

  ~ # mkdir -p/sdcard/CIFS ~ # busybox mount  -v -t cifs -o vers = 3.0, nosuid, nodev, noexec, noatime, rw, hard, context = u: object_r: sdcardfs: s0, nounix, uid = 0, gid = 9997, file_mode = 0660, dir_mode = 0770  , nouser_xattr, port = 445, username = USERNAME, password = PASSWORD///SHARED_DIR/mnt/runtime/write/emulated/0/CIFS  

<sup>* Ядро должно быть построено с использованием CONFIG_CIFS и предпочтительно CONFIG_CIFS_SMB2 , используйте соответственно vers = .
* Для получения подробной информации о параметрах монтирования см. Mount.cifs (8)</sup>

ДРУГИЕ ОПЦИИ?

Другими монтируемыми файловыми системами на основе FUSE являются sshfs и rclone . Latter предлагает широкий спектр протоколов и конфигураций, требуя очень простой настройки.

Кажется, что каждый дистрибутив Busybox, который находится в Google Play, несовместим с NFSv4, а совместим только с NFSv3. . Поэтому я отказался от идеи использовать idmapd на Android.

• Вместо этого я изменил UID и GID на сервере NFS на 4444, чтобы они больше не соответствовали пользователю system .
• Затем я создал нового пользователя на Busybox с тем же именем, UID и GID, что и сервер (в моем дистрибутиве Busybox adduser и addgroup включены).
• Я купил Tasker и загрузил этот набор задач с форума XDA.
• Я выбрал /mnt/nfs для монтирования общего ресурса.

У меня нет времени выяснять, какие из предыдущих пунктов необходимы, а какие не имеют отношения к делу или необязательны. . Если у вас есть идеи, напишите об этом в комментариях.