Problèmes d'permissions pour le directory partagé sur un server

La configuration est que nous avons un VPS exécutant Debian Squeeze, et j'ai mis en place un directory partagé pour nous de partager des files. Jusqu'à présent, j'ai suivi ce guide:

http://www.cyberciti.biz/faq/linux-setup-shared-directory/

J'ai aussi mis l'umask à 002 correctement (voir les commentaires sur ce guide), afin que nous puissions maintenant créer des files et des directorys directement sur le server et que nous ayons tous les deux des droits en lecture / écriture.

Le seul problème est que beaucoup de nos files sont créés sur nos machines locales (les deux exécutant Ubuntu 10.10), puis vides sur le server. Il en résulte que seul le créateur du file / directory possède des permissions en écriture et que l'autre membre du groupe que j'ai configuré pour partager ce dossier ne dispose que d'un access en lecture.

Ma prochaine pensée serait de changer le umask par défaut sur nos machines locales, mais il semble un peu extrême d'avoir à faire cela, et je ne sais pas si c'est un risque de security.

Quelqu'un peut-il me dire s'il y a une meilleure solution à ce que j'essaie d'accomplir, ou si c'est vraiment le cas?

Merci d'avance

Je voudrais utiliser une approche différente et partager les files à travers une list de contrôle d'access sur le directory.

Vérifiez d'abord que les lists de contrôle d'access sont activées sur le système de files où réside le directory (assurez-vous que l'input correspondante dans /etc/fstab contient acl dans la quasortingème colonne). Assurez-vous également que les utilitaires acl sont installés (sur Debian, installez le packageage acl ). Ensuite, accordez aux deux users une permission d'écriture héritable sur le directory.

 setfacl -m user:other_user:rwx /path/to/directory setfacl -d -m user:other_user:rwx /path/to/directory

S'il y a plus de deux users, répétez cette command pour chaque user (l'ACL est implicite pour l'user qui a créé le directory); ou mettez les users dans un groupe (comme vous l'avez déjà fait) et utilisez -m group:group_name:rwx dans la command setfacl .

Désolé, j'étais en train d'épais dans les commentaires. le server sftp est exécuté par root et vous récupérez l'umask de la racine. Vous devriez être capable de résoudre ce problème en éditant votre file /etc/ssh/sshd_config et en changeant la ligne

Subsystem sftp /usr/lib/openssh/sftp-server

 Subsystem sftp /bin/sh -c `umask 0002; /usr/libexec/openssh/sftp-server`

En plus de la réponse de Iain, qui devrait fonctionner (mais attention aux citations intelligentes, et voir ci-dessous pour une mise en garde), en haut de /etc/init.d/ssh vous findez:

 ### BEGIN INIT INFO # Provides: sshd # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: # Short-Description: OpenBSD Secure Shell server ### END INIT INFO ... umask 022

et vous pouvez changer la valeur ici.

Caveat:

de nombreux clients S / FTP essaieront de définir les permissions sur les nouveaux files téléchargés pour qu'ils correspondent aux permissions du système local, alors vérifiez si c'est ce qui se passe. Si c'est le cas, vous pouvez généralement désactiver cette option dans les parameters du client que vous utilisez pour download.

modifier:

J'utilise toujours le sticky-bit pour la propriété du groupe (c.-à-d., je règle toutes les permissions de directory sur 2775) afin que les files et les directorys nouvellement créés héritent de la propriété de groupe correcte.