web-dev-qa-db-fra.com

La racine ne peut pas changer l'autorisation de fichier ou la propriété

Ma Direcotrory est root:

pwd 
/

J'ai le directeur suivant:

drwxrwxrwx   4 root   root     81920 Jun  4 09:25 imr_report_repo

Remarque :imr_report_repo est une part NFS.

Voici la liste fstab inscription pour imr_report_repo:

netapp1:/imr_report_repos_stage  /imr_report_repo  nfs   rw,bg,actimeo=0,nointr,vers=3,timeo=600,rsize=32768,wsize=32768,tcp 1    1
d imr_report_repo

Un fichier à montage:

$ ls -al
-rw-r--r--  1 502     502      1273 Mar 21  2013 imr1_test.txt

L'UID 502 n'existe pas. Si nous ajoutons cette UID/GID localement:

$ groupadd -g 502 jimmy
$ useradd -g 502 -u 502 jimmy

Il apparaît maintenant:

$ ls -al
-rw-r--r--  1 jimmy     jimmy      1273 Mar 21  2013 imr1_test.txt

Maintenant, changez à la racine:

$ su -
$ chown Oracle:oinstall imr1_test.txt
chown: changing ownership of `imr1_test.txt': Operation not permitted
nfschown
8
Stringer

Habituellement root ne dispose pas d'autorisations spéciales sur les actions NFS. Au contraire: root est mappé sur un utilisateur ordinaire (c'est-à-dire un accès "normal" de lecture et d'écriture à des fichiers root).

Vous devez exécuter chown sur le serveur NFS.

10
Hauke Laging

C'est généralement le cas que l'utilisateur racine local sur les clients NFS est interdit d'effectuer ces types d'activités sur les actions montées NFS. NetApp semble ajouter un peu de torsion à ce sujet comme suit:

  • Par défaut, l'option Anon spécifie un UID de 65534. C'est-à-dire que, si vous n'utilisez pas les options racine et anon pour une ressource, les utilisateurs racines de tous les hôtes accèdent à la ressource à l'aide de l'UID 65534.
  • Si l'option Anon spécifie une UID de 65535, l'accès racine est désactivé.
  • Si l'option Anon spécifie un UID de 0, l'accès racine est accordé à tous les hôtes.
  • Si un nom est fourni au lieu d'un UID, ce nom est recherché en fonction de la commande spécifiée dans le /etc/nsswitch.conf Fichier Pour déterminer l'UID correspondant à attribuer par l'option Anon.

Donc, de l'apparence de celui-ci, la part NetApp NFS a l'option par défaut, n ° 1. Vous pouvez confirmer cela en touchant un fichier sur le partage NFS en tant que root et voyez quel iD résulte de cela.

Vous devriez être capable de voir les options exportées de l'action NFS à l'aide de mount -v Sur votre client NFS.

$ mount -v
...
mulder:/export/raid1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,rsize=16384,wsize=16384,addr=192.168.1.1)

Les références

4
slm

Par défaut, un serveur NetApp NFS modifiera, par défaut, les informations d'identification de l'utilisateur root sur un client en UID 65534 sur le serveur, les opérations comme chown échoueront. Pour modifier cela, modifiez la liste d'exportation sur le filer afin que la ligne du système de fichiers ait le paramètre root=clientid, où ClientID est l'adresse IP ou le nom d'hôte du client que vous souhaitez avoir un accès root à ce système de fichiers. Puis courez exportfs -a Si vous utilisez l'interface de ligne de commande sur le déposant.

2
Mark Plotnick

Comme slm commentaire ci-dessus dit,

Il est généralement essentiel que l'utilisateur racine local des clients NFS soit interdit d'effectuer ces types d'activités sur les actions montées NFS

La fonctionnalité utilisée est appelée Squash pourriture . Plus d'informations ICI . Dans mon cas, le seul moyen était de se connecter à désactiver la courge de racine pour ce serveur particulier et de le permettre plus tard.

Une situation similaire que vous rencontrerez si vous utilisez un conteneur docker avec des volumes et le conteneur s'exécute avec un utilisateur non privilégié (E.G. USER Apache). Donc, l'idée des points de chasse NFS doit être r/w uniquement par le owner, et non par root est une pratique de sécurité commune.

0
azbarcea