[gull] sshfs - droits distant

[Arnaud]

Rebonjour,

J'aurais dû lire la page wikipedia avant d'écrire.
Cela fait longtemps que je n'utilise plus sshfs et je l'ai très peu utilisé.

Donc je vais regarder un point qui me tracasse là-dedans, avant de l'ouvrir à nouveau :)
Désolé de mon intervention.

Le 09.11.20 à 21:34, Arnaud a écrit :
> Bonjour, 
> 
> Je dirais que cela ressemble à ce que certaines personnes indiqueraient comme un problème XY :)
> C'est quoi le problème de base ?
> 
> Vous parlez de sftp, mais par expérience, on ne permet pas l'accès à un shell pour ce type d'utilisation.
> Si c'est pour du sftp, je n'en vois pas la raison en tout cas. 
> Si c'est pas pour ça, vous m'avez perdu à partir de là.
> 
> Cordialement,
> Arnaud
> 
> Le 09.11.20 à 17:57, Frederic Dumas a écrit :
>> Pour monter en local un système de fichiers distant, j'ai recours à sshfs. Un utilisateur, créé pour l'occasion avec des droits limités sur la machine distante, vient se connecter à elle à l'aide d'une clé ssh (pas de mot de passe à saisir). Pour l'essentiel, ça fonctionne.
>>
>> Ça a été l'occasion de découvrir que ssh montre les propriétaires et groupes vu du shell de la machine distante, tandis que sshfs les montre vu du shell de la machine locale: UID et GID sont ainsi traduits en propriétaires et groupes différents. Au début, ça laisse pensif. Il faudrait que je teste l'option -o idmap.
>>
>> Comment définir un umask sur la machine distante pour l'utilisateur qui ouvre la session ssh sous-jacente à sftp (si je comprends un peu le principe de sshfs) ? Sur la machine distante, j'ai tenté de définir un umask spécifique dans le .profile de l'utilisateur de circonstance, mais le fichier ne semble pas interprété. J'ai lu que l'option -o umask de sshfs n'est pas la solution, car elle modifie la façon dont les droits s'affichent dans le shell de la machine locale, mais non ceux avec lesquels les nouveaux fichiers sont créé sur la machine distante ?!?
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xEA0DA251B671CC2A.asc
Type: application/pgp-keys
Size: 2434 bytes
Desc: not available
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20201110/5af01afa/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20201110/5af01afa/attachment-0001.sig>