Si elle convient il y a la solution de l’UID unique. Tous les clients accèdent aux fichiers avec le même UID utilisateur. Seulement on ne sais pas qui fait quoi. Et les utilisateurs ne peuvent pas gérer finement leurs droits.

Problème : le umask par défaut est TOUJOURS 0022, ce qui fait que tout fichier créé aura les droits rw– r–– r––. Seul le propriétaire peut écrire et personne d’autre.
Pour partager les fichier, un groupe doit aussi pouvoir écrire.

On peut changer ce umask. Pour la ligne de commande, ça se passe dans les fichiers .bashrc ou .profile, ou dans /etc/profile pour tous les utilisateurs. Pour un partage SFTP, on s’en sort avec un bricolage. Pour le serveur Apache, on s’en sort avec le fichier /etc/apache2/envvars sous Debian.

Si le partage de fichier se fait via un seul service, c’est simple de changer le umask, sinon, c’est compliqué. Et même en changeant tous les umask de tous les services, tout n’est pas parfait : par exemple, Nautilus via SFTP n’en fait qu’à sa tête. Certains clients posent le fichiers et font un chmod derrière : l’enfer. Il y a aussi la puissance des ACL POSIX qui permettent de forcer les droits. Mais là encore, certains clients vous poserons problème.

Enfin, on ne souhaite pas forcément que tous les fichiers soient posés avec l’écriture pour le groupe. On peut souhaiter une meilleure granularité.

D’expérience, j’ai abandonné l’idée du correctif à la source pour me tourner vers un bricolage agissant APRÈS la création du fichier.
La solution la plus simple est bien sûr la tâche cron, qui toutes les X minutes fait un chmod -R g+w sur un dossier. Déjà la solution n’est pas immédiate car désynchronisée de la création de fichiers, et elle rajoute une (très) petite charge supplémentaire à votre système.

Je propose une solution à base d’inotify, qui force les droits dès qu’un fichier est créé :

aptitude install inotify-tools

Et la commande magique :

inotifywait -mrq -e CREATE --format %w%f /tmp/mytest/ | while read FILE; do chmod g=u "$FILE"; done

MAJ 2010-10-30
Pour gérer les espaces en fin de fichiers, et les antislashs :

inotifywait -mrq -e CREATE --format %w%f /tmp/mytest/ | while IFS= read -r FILE; do chmod g=u "$FILE"; done

Merci à vitoreiji (voir commentaires)

La commande inotifywait écoute les événements du dossier /tmp/mytest. Dès qu’un fichier est créé, il est affiché sur la sortie standard. Chaque ligne-fichier est ensuite lue par la boucle while et les droits sont changés. Le g=u donne au groupe les mêmes droits que l’utilisateur (avec g+w, si l’utilisateur pose un fichier rw– ––– –––, les droits deviendraient rw– –w– –––).

Vous pouvez maintenant tester la création/copie de fichiers/dossiers. Même un mkdir -p a/b/c/d/e doit fonctionner.

Pour terminer, on ajoutera tout cela dans un script de démarrage :

vi /usr/local/bin/inotifywait.sh && chmod +x /usr/local/bin/inotifywait.sh
#!/bin/sh
# Take the directory name as argument

inotifywait -mrq -e CREATE --format %w%f "$1" | while read FILE
do
	chmod g=u "$FILE"
done

vi /etc/init.d/inotifywait.sh && chmod +x /etc/init.d/inotifywait.sh
#! /bin/sh

case "$1" in
  start|"")

	rm -f /tmp/inotifywait.log
	/usr/local/bin/inotifywait.sh /path/to/dir/ >/tmp/inotifywait.log 2>&1 &
	
	;;
  restart|reload|force-reload)
	echo "Error: argument '$1' not supported" >&2
	exit 3
	;;
  stop)
	# killall inotifywait ???
	;;
  *)
	echo "Usage: inotifywait.sh [start|stop]" >&2
	exit 3
	;;
esac

:

(sous Debian)

update-rc.d inotifywait.sh defaults

Note : un inconvénient : il y a une limite sur le nombre de fichier surveillés, voir l’option -r dans man inotifywait.

Et enfin la touche finale qui est utile pour que les fichiers créés conservent le groupe du dossier parent : le bit setgid au groupe pour tous les dossiers.

find /path/to/dir -type d -exec chmod g+s {} \;

Liens :

• man inotifywait
• inotify-tools
• http://en.wikipedia.org/wiki/Inotify

Dans le fichier /etc/ssh/sshd_config :

# on utilise le sftp interne d'openssh
# car la commande /usr/lib/openssh/sftp-server ne sera pas disponible dans le chroot
Subsystem sftp internal-sftp

Match group sftp
        ChrootDirectory %h
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

MAJ 17/06/2010 : Attention à la syntaxe ! Les commentaires doivent commencer en début de ligne uniquement, et il ne doit pas y avoir d’espace en fin de la ligne ForceCommand internal-sftp.

Il suffit ensuite de créer des utilisateurs appartenant au groupe sftp, et le tour est joué.
On teste par :

sftp user@myserver.com

Problème si on veut utiliser la commande rsync pour transférer des fichiers, car la commande rsync n’est pas disponible dans le chroot.

En premier lieu, on autorise d’autres commandes que “internal-sftp” en commentant la ligne :

#ForceCommand internal-sftp

Ensuite, on crée l’arborescence suivante dans le dossier chroot :

bin/
bin/bash
bin/rsync
lib/
lib/libncurses.so.5
lib/ld-linux.so.2
lib/libacl.so.1
lib/libpopt.so.0
lib/libattr.so.1
lib/i686
lib/i686/cmov
lib/i686/cmov/libdl.so.2
lib/i686/cmov/libc.so.6

Il s’agit des commandes bash et rsync, ainsi que toutes leurs librairies (que l’on peut obtenir à l’aide de la commande ldd)

Note : l’utilisateur doit avoir /bin/bash comme shell par défaut.

Note 2 : le dossier du chroot doit appartenir à root, bien que ça soit le dossier de l’utilisateur. Pour permettre à l’utilisateur d’écrire dedans, il faut créer un sous dossier où il a les droit. C’est une contrainte importante, mais nécessaire à la sécurité d’un chroot, vous dirons les programmeurs d’OpenSSH.

Références :

• man sshd_config
• http://www.debian-administration.org/articles/590
• http://www.howtoforge.org/chrooted-ssh-sftp-tutorial-debian-lenny
• http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/