Как это происходит, что я, как обычный пользователь, могу изменить Eigentum файла?

У меня есть раздел, который смонтирован через NFS с Netapp SAN. Я могу создавать файлы в этом разделе и менять владельца этих файлов на другого пользователя, любого пользователя, даже на root. Как я могу это делать? Я думал, что ядро будет предотвращать это. Я делал это снова и снова сегодня, используя несколько идентификаторов пользователей для файла.

Я не могу сделать это в /tmp или в своей домашней директории, которая смонтирована локально.

Я никогда раньше не видел такого поведения. Также я отмечаю, что setcap/getcap не найдены на этой машине.

Я проверил возможности своей оболочки, и они все нули:

$ echo $$
15007
$ cat /proc/15007/task/15007/status 
Name:   bash
State:  S (спящий)
SleepAVG:       98%
Tgid:   15007
Pid:    15007
PPid:   14988
TracerPid:      0
Uid:    71579   71579   71579   71579
Gid:    10000   10000   10000   10000
FDSize: 256
Groups: 9000 10000 10001 10013 10018 10420 24611 36021 
...
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

Я на виртуальной машине Red Hat 5.3:

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)

Использую старое ядро:

$ uname -r
2.6.18-274.7.1.el5

Смонтированный NFS использует настройки по умолчанию:

$ cat /etc/fstab
...
mynetapp00:/home /mnt/home nfs defaults 0 0

Для аутентификации пользователей мы используем Windows Active Directory с ldap на стороне Linux:

$ grep passwd /etc/nsswitch.conf 
passwd:     files ldap

Я могу делать что угодно с sudo:

User mikes may run the following commands on this host:
    (ALL) ALL

потому что я один из ADMINS (содержимое /etc/sudoers):

User_Alias      ADMINS = fred, tom, mikes
ADMINS          ALL=(ALL) ALL

…Но я не знаю, как это связано, потому что sudo не задействован. В любом случае, я смог создать файл и сделать его своим владельцем как пользователь “john”, который не найден в /etc/sudoers:

# grep john /etc/sudoers
# su - john
$ touch /mnt/home/blah
$ chown mikes /mnt/home/blah   
$ ls -l /mnt/home/blah
-rwxrwxrwx 1 mikes DomainUsers 0 Oct 23 19:45 /mnt/home/blah

…и chown не алиасирован (но мы это знали, потому что, если бы chown был алиасом или другой программой, тогда я мог бы менять владение и в /tmp):

$ alias
alias l.='ls -d .* --color=tty'
alias ll="ls -l --color=tty"
alias ls="ls --color=tty"
alias vi='vim'
alias which="alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde"
$ which chown
/bin/chown

П.С. Я не шучу:

$ id
uid=71579(mikes) gid=10000(DomainUsers)
$ touch /mnt/home/blah
$ chown john /mnt/home/blah
$ ls -l /mnt/home/blah
-rwxrwxrwx 1 john DomainUsers 0 Oct 23 19:04 /mnt/home/blah
$ id john
uid=37554(john) gid=10000(DomainUsers)
$ chmod 755 /mnt/home/blah
chmod: изменение прав доступа к `/mnt/home/blah': Операция не разрешена
$ rm /mnt/home/blah
$ ls -l /mnt/home/blah
ls: /mnt/home/blah: Нет такого файла или каталога
$ touch /tmp/blah
$ chown john /tmp/blah
chown: изменение владельца `/tmp/blah': Операция не разрешена

Да, chown находится в ведении ядра, но помните, что NetApp вне досягаемости ядра. Для локальных файловых систем ядро преобразует запросы ввода-вывода пользователей в операции ввода-вывода локального оборудования (на устройстве хранения). Для удаленных (например, NFS) файловых систем ядро преобразует запросы ввода-вывода пользователей в сетевые коммуникации, запрашивая/сообщая серверу сделать то, что хочет пользователь.

Нет гарантии, что сервер выполнит запрашиваемое. Например, серверы NetApp могут быть настроены на одновременную поддержку разрешений в стиле Unix и в стиле Windows. Клиенты Unix/Linux будут видеть разрешения в стиле Unix (пользователь, группа, режим и, возможно, ACL). Клиенты Windows будут видеть разрешения в стиле Windows (пользователь, но не группа, атрибуты, ACL и, возможно, расширенные атрибуты). NetApp внутренне хранит комбинацию свойств файла и применяет доступ на основе некоторого неясного, проприетарного алгоритма, так что операция Unix может быть отклонена из-за ограничения разрешений в стиле Windows, которое клиент Unix не может видеть.

Кратко
Сервер NetApp применяет разрешения. Поэтому драйвер NFS для NetApp может быть написан так, чтобы не проводить никаких проверок разрешений, а просто отправлять все запросы пользователей на сервер. Таким образом, решение о разрешении выполнения chown вероятно принимается на 100% на стороне NetApp.

Я не знаю, почему это может произойти. Это может быть багом. Это немного удивляет меня, поскольку NetApp существует 25 лет; я бы ожидал, что такой большой баг уже был бы сообщен и исправлен к настоящему времени. Это может быть настройкой конфигурации на NetApp. Это на самом деле не имеет смысла, но, возможно, администратор сервера не совсем понимает, что он делает (или, возможно, есть какая-то неясная политическая причина, почему это было настроено именно так).

Еще одна догадка заключается в том, что анонимный доступ NFS напрямую сопоставляется с uid 0 – то есть root, поэтому вы можете использовать chown по своему желанию, это можно сделать, используя параметр конфигурации сервера nfs anonuid и в netapp с использованием конфигурации политики экспорта.

Еще одна заметка: вывод оболочки, который вы вставили, не доказывает, что владелец изменился, вы не выполнили “ls -l” перед выполнением “chown”, поэтому еще одна возможность заключается в том, что вы получили доступ к NFS-экспорту анонимно, и сервер был настроен на сопоставление анонимного доступа с именем пользователя “john”, поэтому команде chown не нужно было ничего менять.

ссылки:

https://serverfault.com/questions/539267/nfs-share-with-root-for-anonuid-anongid

https://kb.netapp.com/app/answers/answer_view/a_id/1029865/~/how-to-create-a-root-squash-export-policy-rule-on-clustered-data-ontap-

https://linux.die.net/man/5/exports

Это может пролить некоторый свет. Я использую sshfs. Это позволяет мне монтировать файловые системы с удаленных машин, используя ssh.

Каждый раз, когда я это делаю, все операции с файлами осуществляются пользователем на удаленной машине, с помощью которого я использовал для монтирования файловой системы. Так что, если я сделаю:

sshsf «имя-удаленного-пользователя»@«имя-удаленной-машины»:~ «локальная-точка-монтажа»

Тогда все операции выполняются как удаленный пользователь. И sudo ничего не меняет.

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

NetApp OneFS имеет настройку, которую можно активировать. В текущей версии OneFS это:

vserver nfs modify -chown-mode unrestricted -vserver <имя-сервера>

По умолчанию поведение аналогично Unix, т.е. что пользователи, не являющиеся root, не могут изменять владельца файла.

Однако, если вы установите этот флаг, любой пользователь сможет chown файлы на NFS монтированиях с этого контейнера vserver.

Причина, по которой это наиболее полезно, заключается в том, что вы не разрешаете доступ root к монтированию вообще по причинам безопасности – очень часто “сжимаются” root в привилегированного пользователя, такого как “nobody”, потому что NFS делегирует некоторую доверенность клиентам относительно идентификации и авторизации пользователей.

Это способ разрешить chown без полного обхода ACL файловой системы как root. (Поскольку вы можете “отдать” только то, к чему вы уже имеете доступ, тогда как root игнорирует разрешения на файл)