Votre société de services en logiciels libres

sudoedit pour éditer un fichier en toute sérénité

17 octobre 2017   

Il est parfois nécessaire de déléguer la possibilité de modifier un fichier « système » à un autre utilisateur que root, par exemple bob. Une solution serait d’ajouter une ACL au fichier (par exemple, le fichier /etc/motd), mais je trouve que la gestion des ACL est pénible… laissons-ça aux bons soins de Samba pour faire plaisir aux utilisateurs de Windows.

Si on souhaite utiliser la commande sudo, vous savez certainement que la ligne suivante ne doit pas être placée dans le fichier /etc/sudoers :

bob ALL=(ALL) NOPASSWD: /usr/bin/vi /etc/motd

Pourquoi ? Simplement parce que bob va pouvoir lancer l’éditeur vi en-tant-que-root et donc qu’il pourra éditer d’autres fichiers (avec la commande « :e » de vi) ou bien il pourra obtenir un shell bash toujours avec le compte root (avec la commande « :!bash« ).

Pour éviter l’écueil du lancement d’un shell (ou de toute autre commande), on pourrait ajouter le flag NOEXEC dans le fichier /etc/sudoers, mais cela n’évite pas l’édition d’un autre fichier.

Certains pensent que remplacer vi par nano résoud le problème :

bob ALL=(ALL) NOPASSWD: /usr/bin/nano /etc/motd

Mais avec nano, je peux sauver le contenu du fichier édité sous un nom quelconque et donc je peux changer le contenu de n’importe quel fichier ! Ce n’est pas la bonne solution.

La bonne solution consiste à utiliser la commande sudoedit, équivalente à sudo -e :

bob ALL=(ALL) NOPASSWD: sudoedit /etc/motd

L’utilisateur peut modifier le fichier /etc/motd ainsi :

bob$ sudoedit /etc/motd

Même si l’éditeur par défaut est vi, le lancement d’un shell produira un shell fonctionnant avec le compte de bob et l’édition d’un fichier protégé ne sera pas possible. Pourquoi ? Parce que sudoedit copie le fichier original dans un fichier temporaire appartenant à bob et qu’il n’a besoin des privilèges de root que pour recopier ce fichier temporaire à la place du fichier original, lors de la sauvegarde du contenu du fichier. Le reste du temps, sudoedit (l’éditeur en fait) est exécuté avec le compte de bob, ce que montre l’affichage de la commande ps -edf par exemple.

Démarrer RHEL/Centos7 sans mot de passe « root »

17 octobre 2017   

Contrairement aux anciennes versions et autres distributions Linux pour lesquelles l’ajout du paramètre init=/bin/bash dans les options du noyau suffisait, ces distributions nécessitent l’une des deux options suivantes :

rd.break
init=/sysroot/bin/sh

Notez que « rd.break » stoppe l’exécution du boot lorsque le contrôle passe de initramfs à systemd. Dans les deux cas, il faudra faire un « # chroot /sysroot » et remonter le système de fichiers racine en rw (on aurait pu aussi passer l’option « rw » directement au noyau)

Surveiller la progression d’un transfert de données avec pv

21 avril 2017   

Un article paru sur le site ostechnix.com nous a fait découvrir une nouvelle commande : pv (pour pipe viewer) ! Cette commande permet de suivre la progression d’un transfert de données à travers des « pipes » ou des redirections d’entrée-sortie. Elle est « multi-usage » car elle peut travailler à partir d’un fichier ou bien directement sur STDIN et STDOUT.

Mais, vite, quelques exemples :

1) pour comprendre ce que peut faire pv, testons une copie de fichier réalisée ainsi :

$ pv grosfichier > copie
 97,7MO 0:00:00 [0,992GO/s] [======================>] 100%

2) si la copie s’est réalisée de manière trop rapide, vous pouvez demander à pv de faire des transférer par taille de blocs (ici: 500 Kio) :

$ pv -L 500k grosfichier > copie
 5,86MO 0:00:12 [ 503kO/s] [==>                     ] 11% ETA 0:02:57

3) exemples d’utilisations lors de la création d’archives :

$ tar c Notebooks/ | pv | tar x -C Documents/
$ pv CentOS7.iso | zip > centos.zip
$ dd if=CentOS7.iso | pv | dd of=Downloads/centos7.iso
$ tar -czf - Official/ | (pv -n > mybackup.tgz) 2>&1 | dialog --gauge "Compressing files, please wait..." 10 70 0

 

 

 

Pour que SSHD aille chercher les clés publiques dans un annuaire LDAP…

15 janvier 2016   
Pour que SSHD aille chercher les clés publiques dans un annuaire LDAP…

L’authentification par clé publique est un « must » de sshd par rapport à l’utilisation des mots de passe. Or, bien souvent, les utilisateurs sont définis dans un annuaire LDAP. Le problème devient alors : où stocker les clés publiques des utilisateurs ?

Si la réponse est : dans chaque répertoire de tous les utilisateurs, sur toutes les machines auxquelles ils ont accès, je gage que vous devrez utiliser des outils de déploiement pour éviter cette tâche fastidieuse…

Mais puisque vous avez un annuaire : pourquoi ne pas stocker les clés dans l’annuaire ?

Cette opération est réalisée en 3 étapes :

Enrichir le schéma de l’annuaire

avec OpenLDAP, il fut ajouter la configuration :

dn: cn=openssh-lpk,cn=schema,cn=config
 objectClass: olcSchemaConfig
 cn: openssh-lpk
 olcAttributeTypes: ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey'
 DESC 'MANDATORY: OpenSSH Public key'
 EQUALITY octetStringMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
 olcObjectClasses: ( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' SUP top AUXILIARY
 DESC 'MANDATORY: OpenSSH LPK objectclass'
 MAY ( sshPublicKey $ uid )
 )

Configurer le démon sshd pour qu’il récupère indirectement les clés publiques
Pour cela, ajoutez les deux lignes suivantes dans /etc/ssh/sshd_config :

AuthorizedKeysCommand /etc/ssh/ldap-auth-keys.sh
AuthorizedKeysCommandUser nobody

Vérifiez que l’utilisateur « nobody » existe.

Lors d’une authentification par clé publique, sshd va lancer la commande /etc/ssh/ldap-auth-keys.sh en lui passant le nom de l’utilisateur en paramètre. Cette commande doit retourner la ou les clés publiques associées à l’utilisateur dans l’annuaire, s’il y en a.

Ecrire la commande /etc/ssh/ldap-auth-keys.sh

Le script adéquat peut contenir la commande suivante :

ldapsearch -x '(&(objectClass=posixAccount)(uid='"$1"'))' 'sshPublicKey' |
sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/\n *//g;s/sshPublicKey: //gp'

Maintenant les tests !

Conservez une connexion ssh active sur le serveur et faite un « reload » : si le démon ne redémarre pas, faites un « start » pour avoir l’erreur sur l’écran…

Créer un dépôt GIT à partir de sources existants

18 octobre 2015   

Je n’applique pas toujours les « bonnes » pratiques concernant la mise en gestion de configuration et il m’arrive souvent de créer un dépôt GIT après avoir validé une maquette…et j’oublie toujours les commandes qui me permettent de créer le nouveau dépôt à partir des sources pré-existants. Alors, pour ne plus oublier, je les liste ici.

Je suppose que tous les sources et fichiers à mettre dans GIT sont dans le répertoire ./monappli. Les commandes à exécuter sont :

1.Initialisation du dépôt local :

$ cd ./monapp
$ git init

2.A ce moment là, nous vous suggérons de créer le fichier .gitignore

3.On ajoute les fichiers dans le dépôt local :

$ git add .

4.Puis on les « commit » :

$ git commit -m "commit initial"

5.Au besoin, on définit le dépôt GIT distant :

$ git remote add origin URL_du_dépôt_distant

6.Enfin, on met à jour le dépôt distant à partir du dépôt local :

$ git push origin master