Question autorisation sshfs refusée même pour l'utilisateur root


j'utilise sshfs monter un dossier distant d’un autre serveur sur le serveur local. Le montage du dossier distant fonctionne sans problème à l'aide de la commande suivante:

sshfs -o allow_other someServerFromSSHConfig:/home/data/somefolder/ /some/local/folder

Le problème est que je ne peux pas changer le propriétaire des fichiers en utilisant chown (quelles que soient les autorisations root), je reçois toujours:

chown: changing ownership of ‘/somefolder/file.img’: Permission denied

L'utilisateur qui accède au dossier est membre du groupe de fusibles. Même si j'ajoute des options de montage supplémentaires dans sshfs pour définir le propriétaire en tant que userx:groupx Je ne peux pas changer les permissions avec userx et en utilisant chown -R userx:groupx [...]

Je m'attends à pouvoir définir des autorisations utilisateur pour les fichiers de dossiers montés, mais ce n'est pas le cas.


5
2017-11-15 14:52


origine


Avec quel utilisateur êtes-vous connecté au serveur distant? Lorsqu'il s'agit d'un système de fichiers distant, vous devez avoir accès à ces fichiers avec cet utilisateur et non avec le fichier local. - Jakuje
l'utilisateur est data, data est propriétaire du dossier distant sur la machine distante. - Flatron
plus important serait si elle possède le fichier que vous voulez chown. Sinon, c'est le comportement attendu. Vous ne pouvez pas chown fichier que vous n'avez pas accès. - Jakuje
J'ai fait chow -R data: data / remote / folder après cela en utilisant chow -R userx: groupx / local / monté / folder -> même problème d'autorisation. - Flatron


Réponses:


Comme vous l'avez dit dans des commentaires, vous vous connectez en tant que data @ remote_server Cela signifie que vous ne pouvez pas chown du tout. Le sshfs est juste une abstraction brute, vous n'êtes autorisé qu'aux actions que vous pourriez effectuer à l'intérieur sftp data@remote_server  Toutes les abstractions ont des fuites, celle-ci aussi.

Seul root @ serveur_distant peut chown sur le serveur distant. Peu importe quel utilisateur vous êtes sur local_server.

Notez que pour sftp root@remote_server vous avez généralement besoin de PermitRoot yes ou PermitRoot without-password dans la télécommande /etc/ssh/sshd_config C'est risqué.

PS Par défaut, sshd n'autorise pas les connexions root, à cause de PermitRoot no option. Donc, normalement, vous ne pouvez pas utiliser sshfs root @ remote_host. Si vous souhaitez tester le comportement chown via root, je vous recommande de définir PermitRoot without-password. Cela signifie que root peut se connecter lorsqu'une clé publique est ajoutée à /root/.ssh/authorized_keys. Avec ce paramètre, root ne peut pas se connecter uniquement en fournissant un mot de passe root, il est donc relativement sécurisé.

PS2. Si vous avez besoin d'un peu plus de sécurité, vous pouvez configurer une autre instance de sshd uniquement pour ce partage de fichiers. avec ForceCommand internal-sftp et avec chroot cela aurait considérablement augmenté la sécurité racine, mais il faudrait utiliser un nouveau port TCP et une nouvelle exception de pare-feu.


5
2017-11-19 17:51



Merci pour cette réponse, malheureusement, tant que j'ajoute, disons, clé publique ssh userX sur le serveur de données et monte le stockage avec sshfs à l'aide de userX, je peux chown autant que je le souhaite sans problème, alors dossier externe (avec sshfs) même en définissant les uid et gid sur l'utilisateur qui utilisera le dossier ultérieurement, je ne pourrai pas utiliser chown en tant qu'utilisateur pour lequel j'ai monté le dossier. C'est vraiment étrange. Cependant, je ne veux pas ajouter chaque clé ssh d'utilisateurs à mon serveur de stockage, mais simplement pour monter le dossier par utilisateur. - Flatron
Y a-t-il un moyen de contourner cela? - Flatron
Bien sûr, je ne peux que chowner des dossiers à l'utilisateur avec lequel j'ai monté les dossiers. - Flatron
NFS n'est pas une option pour des raisons de sécurité. Que fait exactement PermitRoot? Utilise actuellement root sur un système distant pour monter des dossiers sur une machine locale, ce qui fonctionne mais n’est pas vraiment une option à long terme. - Flatron


Si vous souhaitez définir la propriété de fichier particulière pour le dossier monté sshfs, vous devez le faire en utilisant uid=USER_ID_N,gid=USER_GID_N et idmap=user options.

  • uid, gid - définit la propriété déclarée des fichiers sur des valeurs données; uid est l'ID utilisateur numérique de votre utilisateur, gid est l'ID groupe numérique de votre utilisateur.
  • idmap - utilisez l'option idmap avec la valeur utilisateur pour traduire l'UID de l'utilisateur qui se connecte. # sshfs -o idmap=user sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876 Cela va mapper l'UID de l'utilisateur distant "sessy" à l'utilisateur local, qui exécute ce processus ("root" dans l'exemple ci-dessus) et le GID reste inchangé.

Une chose à prendre en compte est que votre UID (utilisateur   ID, le numéro unique de votre utilisateur sur un système) n'est pas nécessairement le   même sur les deux hôtes. Lorsque vous ls -l, le nom d'utilisateur associé à   chaque fichier est imprimé dans la troisième colonne. Cependant, dans le système de fichiers,   seuls les UID sont stockés, et ls cherche simplement l’UID et trouve le   nom d'utilisateur qui lui est associé. Sous Unix, ce sont les UID qui importent, pas le   noms d'utilisateur. Donc, si vous êtes 1000 sur l'hôte local et 1003 sur la télécommande   hôte, le répertoire monté sshfs afficherait un nom d'utilisateur différent pour   vos fichiers. Ce n’est pas un problème, cependant, car le serveur ssh sur   la machine distante est ce qui lit et écrit réellement les fichiers. Alors   même s’il apparaît dans ls -l sous un UID différent, toute modification sera   se faire via le serveur ssh sur l’hôte distant, qui utilisera le   UID correct pour la machine distante. Des problèmes peuvent survenir si vous essayez   d’utiliser un programme qui examine les UID des fichiers (par exemple, ls imprime le mauvais   Nom d'utilisateur).

le idmap = utilisateur Cette option garantit que les fichiers appartenant à l'utilisateur distant sont   appartenant à l'utilisateur local. Si vous n'utilisez pas idmap = user, les fichiers de la   répertoire monté peut sembler appartenir à quelqu'un d'autre, car   votre ordinateur et l'ordinateur distant ont des idées différentes sur la   ID utilisateur numérique associé à chaque nom d'utilisateur. idmap = utilisateur ne sera pas   traduire les UID pour d'autres utilisateurs.

Cité de: https://help.ubuntu.com/community/SSHFS


1
2017-11-19 11:23



En utilisant: sshfs -o idmap=someuser server:/home/user/somefolder/temp/ /home/localuser/someotherfolder/ Donne moi: fuse: unknown option 'idmap=someuser' - Flatron
ok nvm -> idmap = someuser -> idmap = utilisateur, mais toujours pas de succès, je pense que le problème est ce que kubanczyk a dit dans sa réponse. - Flatron
Notez s'il vous plaît, idmap=user pas someuser. - Diamant
Oui, malheureusement, cela n’aide pas non plus. allow_other ou même gid [...] uid Aidez-moi. - Flatron
Voir mon commentaire sur la deuxième réponse. C’est assez incroyable, il ne devrait pas être aussi difficile de monter plusieurs dossiers d’un système distant sur plusieurs dossiers (pour des utilisateurs distincts) sur le système local, en utilisant un seul utilisateur sur la machine locale et en accordant toutes les autorisations nécessaires à chaque utilisateur. peuvent chown leurs dossiers pour eux-mêmes. - Flatron