$ sudo gems install rails -y

Oui mais voilà, Netbeans n’utilise pas sudo. Pour que Netbeans puisse gérer les gemmes lui-même, il lui faut donc les droits d’écriture sur le dossier /var/lib/gems et ses sous-répertoires. Le plus naïf est de donner tous les droits en écriture, mais c’est mal ! Sinon, on peut aussi créer un groupe nommé rubygems et donner le droit d’écriture à ce groupe. Cette approche est meilleure mais un problème se pose lorsque l’utilisateur y crée un nouveau fichier ou dossier : non seulement celui-ci appartient à l’utilisateur et non pas à root, mais en plus le groupe n’a pas le droit d’écriture. C’est là qu’interviennent les ACLs…

Démonstration avec l’utilisateur foo.

On crée un groupe ruby gems et on s’y ajoute

$ sudo addgroup rubygems
$ sudo adduser foo rubygems

On se déconnecte puis reconnecte pour prendre en compte le nouveau groupe, puis on vérifie les permissions

$ sudo mkdir /test
$ sudo chgrp rubygems /test
$ sudo chmod g+w /test
$ ls -ld /test
drwxrwxr-x 2 root rubygems 4096 2008-12-03 22:16 /test
$ touch /test/bar
$ ls -l /test/bar
-rw-r--r-- 1 foo foo 0 2008-12-03 22:21 /test/bar

Ce n’est pas bon du tout. On préférerait avoir quelque chose comme -rw-rw-r-- 1 foo rubygems afin que les autres membres du groupe rubygems puissent eux aussi modifier ce fichier. De manière plus générale, on veut que :

• le groupe soit rubygems ;
• les permissions du groupe soient rwx pour un dossier et rw- pour un fichier ;
• et que les permissions des autres soient r-x pour un dossier et r– pour un fichier.

La partie qui va suivre est issu des connaissances acquises grâce à l’article Group sharing a directory.

Attribuer le groupe automatiquement

Il est simple d’affecter le groupe rubygems automatiquement à chaque nouveau dossier créé dès qu’on connait l’astuce : il suffit de lever le bit ’set groupid’ du groupe du dossier pour que tout nouveau fichier ou dossier créé appartienne au groupe du dossier parent plutôt qu’au groupe de l’utilisateur

$ sudo chmod g+s /test
$ ls -ld /test
drwxrwsr-x 2 root rubygems 4096 2008-12-05 07:54 /test
$ touch f
$ mkdir /test/d
$ ls -l /test
total 4
drwxr-sr-x 2 foo rubygems 4096 2008-12-05 07:59 d
-rw-r--r-- 1 foo rubygems    0 2008-12-05 07:59 f
$ cd /test/d
$ touch bar
$ ls -l
-rw-r--r-- 1 foo rubygems 0 2008-12-05 08:00 bar

Permettre l’écriture au groupe automatiquement

Cette solution fait usage des ACLs. La commande

$ sudo setfacl -m default:user::rwx,default:group::rwx,default:mask:rwx,default:other:r-x /test

permet de définir les permissions par défaut pour les futurs fichiers du dossier /test. La commande est longue et peut être abrégée en

$ sudo setfacl -m d:u::rwx,d:g::rwx,d:m:rwx,d:o:r-x /test

Si la commande setfacl ne fonctionne pas, c’est parce que l’option acl n’est pas active pour votre volume. Assurez-vous d’avoir une ligne qui ressemble contienne l’option acl dans votre /etc/fstab :

/dev/hda2 / ext3 defaults,acl 0 1

Ensuite remontez votre volume pour prendre en compte les modifications

sudo mount / -o remount

Observons maintenant d’un peu plus près la définition d’ACLs

$ sudo setfacl -m d:u::rwx,d:g::rwx,d:m:rwx,d:o:r-x /test
$ ls -ld /test
drwxrwsr-x+ 3 root rubygems 4096 2008-12-05 07:59 /test
$ getfacl /test
getfacl: Removing leading '/' from absolute path names
# file: test
# owner: root
# group: rubygems
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Le + à droite des permissions affichées par la commande ls indique qu’il y a des permissions supplémentaires visibles par getfacl. Ce dernier permet d’afficher les permissions définies avec setfacl. Essayons de créer des fichiers.

$ cd /test
$ touch polop.txt
$ mkdir hello
$ ls -l
total 16
drwxr-sr-x  2 foo rubygems 4096 2008-12-05 08:00 d
-rw-r--r--  1 foo rubygems    0 2008-12-05 07:59 f
drwxrwsr-x+ 2 foo rubygems 4096 2008-12-05 08:17 hello
-rw-rw-r--+ 1 foo rubygems    0 2008-12-05 08:17 polop.txt
$ getfacl hello
# file: hello
# owner: foo
# group: rubygems
user::rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Les ACLs ont bien rempli leur rôle : les nouveaux fichiers créés ont la permission d’écriture pour le groupe et ont aux aussi les ACLs définis (notez le +).

Application au dossier de gemmes de ruby

Il nous faut définir le groupe les permissions pour tout fichier ou dossier existant du dossier /var/lib/gems et les ACLs ainsi que le ’set groupid’ bit pour tout dossier, sans oublier de changer le groupe pour qu’il devienne rubygems.

$ sudo chgrp -R rubygems /var/lib/gems
$ sudo chmod -R -s,g=rwX,o=rX /var/lib/gems
$ for dir in $(find /var/lib/gems -type d) ; do
> sudo chmod g+s "$dir"
> sudo setfacl -m d:u::rwx,d:g::rwx,d:o:r--,d:m:rwx "$dir"
> done

notez que si vous étiez sous zsh, vous auriez pu écrire

$ sudo chgrp rubygems /var/lib/gems/**/*
$ sudo chmod -s,g=rwX,o=rX /var/lib/gems/**/*
$ sudo chmod g+s /var/lib/gems/**/*(/)
$ sudo setfacl -m d:u::rwx,d:g::rwx,d:o:r--,d:m:rwx /var/lib/gems/**/*(/)

Voilà ! désomais vous pouvez taper

$ gems install rails -y

en simple utilisateur, ce qui signifie que d’autres programmes tiers comme NetBeans peuvent également installer des gemmes.

Autres applications

On peut trouver d’autres application très utiles au partage de dossier par ACL. Comme ça de tête :

• Quand votre serveur web est partagé entre plusieurs personnes, partager le dossier /var/www d’apache pour que l’utilisateur système www-data ait le droit d’écriture sur tous les fichiers sans donner ces droits à tout le monde ;
• Partager des fichiers sur un disque dur externe pour que chacun puisse y gérer ses films et photos sans se retrouver bloqué quand on veut déplacer ou supprimer certains éléments créés par d’autres utilisateurs.

sudo echo 'Acquire::http::Proxy "http://proxy.mynetwork.com:1234/";' > /etc/apt/apt.conf.d/proxy

ou plus simplement en définissant les paramètres du proxy dans la variable d’environnement http_proxy (ou ftp_proxy dans le cas d’un miroir ftp).

export http_proxy='http://proxy.mynetwork.com:1234/'

Si le proxy est un proxy authentifiant, alors il faut également préciser le login et le mot de passe dans http_proxy.

export http_proxy='http://login:pwd@proxy.mynetwork.com:1234/'

Évidemment, si vous avez un dépôt debian miroir sur votre réseau interne, vous n’avez pas besoin de définir tout ça. Cependant, si vous voulez également accéder aux dépôts externes, c’est là que ça se complique : si vous définissez http_proxy, le dépôt interne devient inaccessible car apt tente de passer par le proxy, et si vous ne le définissez pas, les depôts externes sont inaccessibles car vous ne passez plus par le proxy. Il faut donc procéder autrement.

Une solution est d’utiliser la variable no_proxy. Cette variable définit les hôtes qui ne nécessitent pas un accès via proxy.

Par exemple

export no_proxy='127.0.01,.mynetwork.com,192.168.78.100'

n’utilisera pas le proxy pour accéder à 127.0.0.1, à n’importe quel hôte du domaine mynetwork.com ou à 192.168.78.100. Attention, l’utilisation de wildcards dans no_proxy ne fonctionnera pas. Ainsi écrire ce qui suit n’empêchera pas d’essayer d’utiliser le proxy pour accéder à wiki.mynetwork.com.

# wildcards dont work
export no_proxy='127.0.01,*.mynetwork.com'

Définir http_proxy et no_proxy dans $HOME/.bashrc permettra donc d’accéder à n’importe quel dépôt, qu’il soit sur le réseau interne ou à l’extérieur. Prenons l’exemple de deux dépôts, l’un sur l’hôte deb.mynetwork.com, l’autre sur l’hôte fr.archive.ubuntu.com. Il faut définir

export http_proxy='http://login:pwd@proxy.mynetwork.com:1234/'
export no_proxy='127.0.01,deb.mynetwork.com'

Mais si vous utilisez sudo apt-get pour installer un paquet, ça ne fonctionne toujours pas. C’est parce que sudo filtre les variables d’environnement pour des raisons de sécurité. Pour constater quelles variables sont filtrées et comment :

sudo sudo -V

On y voit que la variable http_proxy est préservée, mais pas no_proxy. Pour y remédier, il va falloir éditer le fichier /etc/sudoers.

sudo visudo

et rajouter la ligne suivante

Defaults        env_keep+="no_proxy"

Attention à bien mettre des double-quotes et non des simple-quotes.

Si vous êtes sous Ubuntu, le fichier devrait ressembler à ça

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults

Defaults        env_keep+='no_proxy'
Defaults        !lecture,tty_tickets,!fqdn

# User privilege specification
root    ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

Ainsi, vous pouvez installer des paquets provenant de votre réseau local ou de l’extérieur.

L’avantage de cette solution, c’est qu’elle est valable pour tous les programmes : par exemple l’installation du paquet msttcorefonts va télécharger les polices true type microsoft sur le net en utilisant wget. Si vous êtes derrière un proxy et qu’aucun proxy n’est défini dans le fichier $HOME/.wgetrc, le fichier /etc/wgetrc ou dans la variable d’environnement http_proxy, le téléchargement échouera. En définissant la variable d’environnement http_proxy ça fonctionne comme un charme.

Petite astuce supplémentaire, si votre proxy requiert une authentification, vous n’avez pas envie que tout le monde connaisse votre mot de passe en regardant votre .bashrc.

Une solution est de mettre la définition dans un fichier $HOME/.proxy puis de l’appeler depuis le bashrc.

fichier $HOME/.proxy

#!/bin/bash
# proxy settings
export http_proxy='http://login:pwd@proxy.mynetwork.com:1234/'
export no_proxy='127.0.01,deb.mynetwork.com'

changer les droits d’accès et modifier son bashrc

chmod go-rw $HOME/.proxy
echo 'source $HOME/.proxy' > $HOME/.bashrc