Environnement d'exécution, login shells et non-login shells

Arbiel · Le 07/02/2019, à 01:27

Bonsoir à tous

Ma configuration se trouve incompatible avec la manière dont sont traitées les partitions chiffrées. Cette incompatibilité se traduit par le fait que l'initrd recalculé lors de mises à jour avec installation d'un nouveau noyau n'est pas correct. Pour le recréer, je dois exécuter update-initramfs après avoir modifié mon fichier crypttab. La raison en est que, lors du démarrage de mon système, le fichier crypttab ne doit pas référencer les partitions chiffrées montées par fstab, alors qu'il doit les référencer lors du calcul de l'initrd.

Les scripts exécutés lors du démarrage du système sont contenus dans des fichiers (non-login shell ?) différents de ceux qui sont exécutés lorsque j'ouvre une session utilisateur (login shells ?). Les mises à jour se font lorsque j'ai ouvert une session utilisateur, et donc après que les login shells ont été exécutés, alors que le démarrage se fait hors session utilisateur, et donc après que les non-login shells ont été exécutés.

Je suppose que, en créant deux fichiers crypttab différents, je peux initialiser la variable d'environnement pour désigner le bon fichier crypttab selon qu'il s'agit du démarrage ou de l'ouverture de ma session utilisateur. Malheureusement, la lecture de la page man de bash ne m'a pas permis de bien comprendre quels fichiers contiennent les login shells et ceux qui contiennent les non-login shells.

Et je ne suis pas certain non plus d'avoir bien compris la distinction entre les login shells et les non-login shells

Merci d'avance à quiconque pourra me renseigner.

bruno · Le 07/02/2019, à 11:13

Bonjour,

Abriel a écrit :

Et je ne suis pas certain non plus d'avoir bien compris la distinction entre les login shells et les non-login shells

On va faire très simple

Un login shell est un shell obtenu après connexion avec un non d'utilisateur et un mot de passe. Tout le reste, et donc l'exécution des scripts, se fait en non-login shell.

Mettons les choses en français pour mieux comprendre :
login shell = interpréteur de commandes avec ouverture de session
non login shell = interpréteur de commandes sans ouverture de session

Un script exécuté au démarrage, ou une tâche cron du système, est dans le contexte d'un interpréteur de commandes non-interactif et sans ouverture de session (non-login, non interactive shell). Il ne connaît pas les variables d’environnement définies dans /etc/profile* ni ~/.profile (en particulier $PATH). Il connaît éventuellement celles définies dans ~/.bahrc

Un script exécuté dans une session utilisateur préalablement ouverte est dans le contexte d'un interpréteur de commande non-interactif avec ouverture de session (c'est formellement faux mais je simplifie). Il connaît les variables d'environnement définies dans /etc/profile*, ~/.profile, /etc/bash.bashrc, et ~/.basrhc

N.B. : je ne pense pas que ces considérations aient quelque chose à voir avec ton problème de partitions chiffrés et de mises à jour. Les scripts de démarrage et ceux de mises à jour s'exécutent en tant que root dans le même contexte. Cela ressemble plus à un bogue ou à une mauvaise configuration.

Dernière modification par bruno (Le 07/02/2019, à 11:18)

Arbiel · Le 07/02/2019, à 14:15

Merci pour ces explications

bruno a écrit :

N.B. : je ne pense pas que ces considérations aient quelque chose à voir avec ton problème de partitions chiffrés et de mises à jour. Les scripts de démarrage et ceux de mises à jour s'exécutent en tant que root dans le même contexte. Cela ressemble plus à un bogue ou à une mauvaise configuration.

Avant l'introduction de system-d, seule la partition racine, lorsqu'elle est chiffrée, nécessitait l'ouverture par l'initrd. Les autres partitions (home, …) l'étaient par les scripts de démarrage, sous réverse que l'option "noauto" ne soit pas présente dans les lignes de crypttab.

Depuis l'introduction de system-d, donc depuis la 16.04, toutes les partitions chiffrées montées par fstab doivent être ouvertes par initrd. Les lignes correspondantes sont identifiées dans crypttab par une nouvelle option, initramfs. Jusque là, pas de problème.

L'ennui provient de ce que les scripts de démarrage se mélangent un peu les pieds, ce qui induit des attentes inutiles et importantes. J'ai ouvert cette discussion. à ce sujet. L'option "noauto", qui fonctionne parfaitement pour d'autres partitions chiffrées éventuellement décrites dans crypttab, ne fonctionne apparemment pas pour les partitions marquées comme "initramfs". J'ai bien sûr essayé, sans succés. J'ai demandé dans Ask Ubuntu comment paramétrer correctement ces lignes. Pas de réponse.

La seule solution que j'ai trouvée est l'annulation en les commentant des lignes ouvertes par initrd. Ceci supprime les attentes au démarrage.

L'installation d'un nouveau noyau entraîne l'installation de l'initrd correspondant. Comme le fichier crypttab alors actif ne désigne plus de partitions à ouvrir par l'initrd, il en résulte un initrd inefficace. La mise à jour de grub qui en découle propose en premier choix le démarrage par cet initrd ineffiicace, et par suite le système initialisé par system-d se plante. La solution est alors de démarrer avec le noyau précédent, de modifier le fichier crypttab, de créer le nouvel initrd, de modifier à nouveau le fichier crypttab. Tout ceci n'est pas très pratique.

Or il se trouve que le fichier /lib/cryptsetup/cryptdisks.functions

remi@remi-Vostro-3550:~$ sudo head -15 /lib/cryptsetup/cryptdisks.functions
#
# This file is for inclusion with
#    . /lib/cryptsetup/cryptdisks.functions
# and should not be executed directly.

PATH="/usr/sbin:/usr/bin:/sbin:/bin"
TABFILE=${TABFILE-"/etc/crypttab"}
CRYPTDISKS_ENABLE="Yes"

#set -x

# Sanity check #1
[ -x /sbin/cryptsetup ] || exit 0

. /lib/lsb/init-functions
remi@remi-Vostro-3550:~$

laisse entrevoir la possibilité d'initialiser la variable d'environnement TABFILE à "/dev/null" dans le contexte de démarrage et à ne pas l'initialiser à l'ouverture de mes sessions. J'ai bon espoir qu'alors, en ne commentant plus les lignes "initramfs" de crypttab, les mises à jour qui incluent la mise en œuvre d'un nouveau noyau n'aboutiront plus à un échec au démarrage suivant.

Arbiel

Dernière modification par Arbiel (Le 07/02/2019, à 14:17)

Arbiel · Le 07/02/2019, à 16:13

Pour en revenir à tes explications :

ouverture de session : validation de mon mot de passe à l'ouverture de la session graphique, que ce soit au démarrage ou à la sortie de veille ou d'hibernation, ou après changement d'utilisateur (exécution de l'un des fichiers /etc/profile*, ~/.profile, /etc/bash.bashrc, et ~/.basrhc, le vais vérifier l'ordre dans le man et à la lecture de ceux de ces fichiers qui existent)
fin de le session : changement d'utilisateur, passage en veille ou en hibernation, arrêt du système (exécution de ~/.bash_logout)
Dans tous ces cas ~=/home/${USER}.

Dans le fonctionnement que je cherche à mettre en œuvre
à l'ouverture de session ; création d'un lien crypttab vers le crypttab complet (celui qui permet de restaurer initrd, et d'ouvrir d'autres partitions chiffrées)
à la fermeture : suppression du lien crypttab pour qu'au redémarrage suivant les scripts n'attendent pas vainement un événement qui ne survient pas.

Je vais essayer.

Par ailleurs,

Un script exécuté au démarrage, ou une tâche cron du système, est dans le contexte d'un interpréteur de commandes non-interactif et sans ouverture de session (non-login, non interactive shell). Il ne connaît pas les variables d’environnement définies dans /etc/profile* ni ~/.profile (en particulier $PATH). Il connaît éventuellement celles définies dans ~/.bahrc

Dans ce cas, ~ = /root ?

bruno · Le 07/02/2019, à 16:22

Pour ce que tu essaies de faire, je ne peux rien dire car je ne comprends pas le problème. Et je n'ai jamais constaté qu'une mise à jour du noyau empêchait l'accès aux volumes chiffrés (chiffrement à l'installation).

Pour la dernière question : oui, mais en général le /root/.bashrc est vide.

Arbiel · Le 07/02/2019, à 18:01

Désolé de n'avoir pas su être clair dans mes explications.

Il ne s'agit en aucun cas de dire qu'une mise à jour du noyau empêche l'accès aux partitions chiffrées, mais de dire que, compte tenu de ce qui se passe au démarrage (délais), il me faut supprimer du fichier crypttab les lignes relatives aux partitions chiffrées que l'initrd doit maintenant ouvrir, pour que le démarrage ne soit pas drastiquement ralenti. Cette suppression a pour conséquence que la création d'un nouveau initrd (résultant de la mise en œuvre d'un nouveau noyau) produit un initrd incapable d'ouvrir les dites partitions.

D'où toute une gymnastique que j'aimerais supprimer.

Je ne chiffre pas à l'installation. J'installe sur des partitions (des volumes logiques) préalablement chiffrées et montées. Et je chiffre uniquement ce que je considère confidentiel et non tout le groupe de volumes.

J'espère avoir été un tout petit peu plus clair.

Pour la dernière question : oui, mais en général le /root/.bashrc est vide.

Certes, mais il ne tient qu'à moi d'y enregistrer un script.

Dernière modification par Arbiel (Le 07/02/2019, à 18:03)

LeoMajor · Le 09/02/2019, à 17:11

bonjour,

ouverture de session : validation de mon mot de passe à l'ouverture de la session graphique, que ce soit au démarrage ou à la sortie de veille ou d'hibernation, ou après changement d'utilisateur ...Je ne chiffre pas à l'installation. J'installe sur des partitions (des volumes logiques) préalablement chiffrées et montées. Et je chiffre uniquement ce que je considère confidentiel et non tout le groupe de volumes....

je pense qu'il faut que tu passes par une libpam ( pam cryptsetup ). à vérifier libpam-mount. Faire d'abord les tests avec ssh par exemple, et ensuite fixer le service voulu (lightdm, gdm*, ..)
Pour la sortie de la mise en veille /hibernation, c'est pareil. ( ex: /etc/pam.d/xscreensaver ) . Eviter les common-* sous pam, qui ont une portée sur l'ensemble des services saus si cela que tu veux.
exemple;

exemple pour carte à puce (pki, pkcs11)
grep -ri "pkcs11" /etc/pam.d

/etc/pam.d/sshd:#auth       sufficient   pam_pkcs11.so
/etc/pam.d/lightdm-autologin.dpkg-old:#auth       sufficient   pam_pkcs11.so debug config_file=/etc/pam_pkcs11/pam_pkcs11.conf
/etc/pam.d/lightdm.dpkg-old:#auth       sufficient   pam_pkcs11.so debug config_file=/etc/pam_pkcs11/pam_pkcs11.conf
/etc/pam.d/lightdm.dpkg-old:#session optional   pam_pkcs11.so debug config_file=/etc/pam_pkcs11/pam_pkcs11.conf
/etc/pam.d/xscreensaver.old:#auth       sufficient   pam_pkcs11.so

Arbiel · Le 09/02/2019, à 19:46

Bonsoir

Je crois que la solution à mon problème est tout autre.

Mon problème est le suivant. Quoique j'aie pu essayé dans les options du fichier crypttab pour l'ouverture de mes volumes logiques chiffrés nécessaires au montage par fstab, j'ai besoin de deux fichiers crypttab différents :

l'un dans lequel les lignes relatives à ces volumes logiques sont commentées, pour éviter des délais importants lors du démarrage de mon PC,

l'autre dans lequel toutes les lignes relatives à ces volumes logiques sont laissées intactes, de sorte que, dans le cas où un nouveau noyau serait chargé lors d'une mise à jour, le fichier initrd correspondant, créé dans la foulée de cette mise à jour, contienne les instructions nécessaires à l'ouverture de ces volumes logiques.

Je suis maintenant en panne du fait d'une mauvaise manipulation de ma part pour essayer de résoudre le problème, et je ne peux pas tester la solution que j'envisage maintenant, à savoir,

définir un fichier vide, de sorte que le démarrage ne soit pas ralenti
définir un second fichier, contenant toutes les lignes nécessaires au traitement des volumes logiques chiffrés, monté par fstab sur le fichier vide.

Arbiel

maxire · Le 09/02/2019, à 21:49

Salut,

Pour résumer, je crois comprendre que tu as supprimé de /etc/cryptab toutes références aux volumes chiffrés montés via fstab ceci afin d"accélérer le démarrage système (drôle d'idée mais bon pourquoi pas).
La conséquence est que maintenant l'image initiale système est générée sans tenir compte de ces volumes chiffrés et ceux-ce ne sont donc pas montés.
La solution que tu appliques est de remettre les références des volumes chiffrés dans /etc/cryptab puis de générer un nouvelle image initiale système puis de corriger /etc/cryptab.

Je crois que tu aurais pu clairement expliquer ceci dès le premier message qui est parfaitement obscur.

Je ne vois qu'une solution, écrire un script à insérer dans l'image initiale, tu as le répertoire /etc/initramfs-tools/scripts pour cela.
Plus d'information dans la page man de initramfs-tools, tout est ici : http://manpages.ubuntu.com/manpages/bio … ols.8.html

Bon codage !

Arbiel · Le 09/02/2019, à 23:02

Bonsoir

maxire a écrit :

drôle d'idée mais bon pourquoi pas

parce que, sinon, le démarrage de mon PC prend presque 3', comme je l'ai indiqué ici, ce qui n'est pas vraiment satisfaisant. Le fait de supprimer de crypttab les volumes chiffrés ouverts par initrd réduit ce délai à environ 1', ce qui n'est pas excellent, mais reste supportable.

Comme tu l'as parfaitement compris, une telle situation ne permet pas de créer une image initiale correcte.

J'ai appliqué pendant un moment une solution manuelle qui consiste, après échec du démarrage avec un nouveau noyau, à modifier crypttab et à recréer une image initiale, puis à revenir à un fichier crypttab "dégradé".

Je voudrais ne plus avoir à intervenir de cette façon. Les délais me semblent se passer avant le montage des fichiers par fstab. D'où mon idée de monter un fichier "complet" sur un fichier vide. A chaque démarrage, le fichier est vide, donc pas de délai, et en cas de création d'une image initiale, il ne l'est plus, donc une image initiale correcte.

J'ai essayé d'écrire des scripts, peut-être pas au bon endroit, et j'ai détérioré mon système. Je n'arrive pas à réparer, de sorte que je suis sur le point de réinstaller.

Arbiel

maxire · Le 09/02/2019, à 23:19

Bonne chance dans ta récupération système !

Plutôt que de bricoler, le plus simple est d'écrire un script exécuté par l'image initiale qui ferait en gros :

cryptsetuo luksOPen device map-name

ceci pour chaque volume chiffré et de ne plus se préoccuper de /etc/crypttab.

C'est juste une idée, je n'ai pas testé.
Donc lis la page man de initramfs-tools elle te permettra de comprendre comment insérer ce script ou un autre dans l'image initiale.

Arbiel · Le 10/02/2019, à 12:10

Bonjour

Je vais suivre tes conseils. Je n'avais effectivement pas envisagé d'écrire un script pour l'image initiale. C'est évidemment mieux que de bricoler, d'autant que mes bricoles ont rendu mon système inexploitable, et que le retour en arrière sur ce que j'ai fait lors de ma dernière utilisation du système ne le remet pas sur pieds.

Merci maxire.

Arbiel

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 07/02/2019, à 01:27

Environnement d'exécution, login shells et non-login shells

#2 Le 07/02/2019, à 11:13

Re : Environnement d'exécution, login shells et non-login shells

#3 Le 07/02/2019, à 14:15

Re : Environnement d'exécution, login shells et non-login shells

#4 Le 07/02/2019, à 16:13

Re : Environnement d'exécution, login shells et non-login shells

#5 Le 07/02/2019, à 16:22

Re : Environnement d'exécution, login shells et non-login shells

#6 Le 07/02/2019, à 18:01

Re : Environnement d'exécution, login shells et non-login shells

#7 Le 09/02/2019, à 17:11

Re : Environnement d'exécution, login shells et non-login shells

#8 Le 09/02/2019, à 19:46

Re : Environnement d'exécution, login shells et non-login shells

#9 Le 09/02/2019, à 21:49

Re : Environnement d'exécution, login shells et non-login shells

#10 Le 09/02/2019, à 23:02

Re : Environnement d'exécution, login shells et non-login shells

#11 Le 09/02/2019, à 23:19

Re : Environnement d'exécution, login shells et non-login shells

#12 Le 10/02/2019, à 12:10

Re : Environnement d'exécution, login shells et non-login shells

Pied de page des forums