Pourquoi sudo -i ne définit-il pas XDG_RUNTIME_DIR pour l'utilisateur cible?

XDG_RUNTIME_DIRest nécessaire pour systemctl --usertravailler.

J'ai configuré le serveur Ubuntu 16.04 pour exécuter les sessions utilisateur systemd. Maintenant, lorsque j'essaie de les administrer, je trouve que lorsque vous changez un utilisateur via sudo -u $user -iou même su - $user, l'environnement n'a pas XDG_RUNTIME_DIRdéfini, empêchant systemctl --userde fonctionner. Cependant, quand je suis sshdirectement dans cet utilisateur, il est correctement défini.

Si je comprends bien la documentation, cela doit être défini libpam-systemdlors de la création de la session utilisateur. La tranche utilisateur est démarrée correctement, car le répertoire vers lequel XDG_RUNTIME_DIRdoit pointer ( /run/users/$uid) existe. J'hésite à le coder en dur, disons, .bash_profileparce que cela semble hacky (bien que fonctionnel), quand pam devrait s'en occuper.

Je peux, bien sûr, ajouter XDG_RUNTIME_DIRà env_keepdans sudoers, mais ce serait tout simplement préserver l'environnement de l'utilisateur sudoing, ce qui est pas ce que je veux. Je veux l' environnement de l'utilisateur cible .

Ce que je me demande vraiment, cependant, c'est comment se fait-il que la session soit correctement configurée avec ssh, mais pas avec suou sudo -i?

J'ai reproduit ce problème sur mon système Fedora 25.

J'ai trouvé une condition très suspecte dans le code source. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 On dirait qu'il a été écrit avec un sudoesprit normal mais pas sudo -u non-root-user.

machinectl shell --uid=non-root-user travaillé comme vous l'avez demandé.

systemd-run ne semble pas fonctionner comme souhaité, malgré la référence à celle-ci dans la documentation de machinectl.

Certaines commandes machinectl ne fonctionnent pas si vous avez activé SELinux pour le moment, et ces commandes spécifiques ne fonctionnaient pas pour moi jusqu'à ce que je le fasse setenforce 0. Cependant, je suis en train d'essayer de contourner le problème pour que machinectl fonctionne comme je le veux pour SELinux, il est donc possible que mon bidouillage soit ce qui provoque, par exemple, un machinectl shelldépassement de délai.

EDIT: Je pense que ce code a été introduit après cette discussion . Et apparemment su -/ sudo -ipourrait fonctionner, mais personne ne l'a (encore) mis en œuvre.

Ce que je me demande vraiment, cependant, c'est comment se fait-il que la session soit correctement configurée avec ssh, mais pas avec su ou sudo -i?

https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

Désolé, mais "su" est un outil pour modifier temporairement les identités des utilisateurs et très peu d'autres informations d'identification de processus. Ce n'est pas un outil pour ouvrir une session de connexion complètement nouvelle. Une nouvelle session de connexion a une configuration très bien définie et immaculée, n'héritant d'aucune autre session, mais ce n'est vraiment pas le cas pour les changements de "su" uid: la plupart de l'environnement d'exécution est hérité, dans de nombreux et non évidents façons, par exemple les contextes MAC, les contextes d'audit, les contextes de groupe de contrôle, les contextes d'espace de noms, la planification, la granularité du temporisateur,…

si vous voulez une nouvelle session complète, utilisez quelque chose comme "login machinectl" ou "shell machinectl", qui obtiendra en fait un environnement de déconnexion entièrement propre et indépendant, sans aucune propriété de processus cachée qui fuit d'où vous l'appelez.

les sessions de déconnexion sont pour la plupart liées au concept de session d'audit, et les sessions d'audit ne sont pas affectées par "su", en fait, elles sont définies comme étant "fermées", c'est-à-dire d'une manière qui si un processus est entré une fois dans une session, il restera toujours avec lui, et ses enfants aussi, c'est-à-dire que le seul moyen d'obtenir une nouvelle session est de supprimer quelque chose du PID 1 (ou quelque chose de similaire) qui n'a jamais fait partie d'une session.

Ou pour dire les choses différemment: les éléments que vous invoquez via "su" apparaîtront très bien dans "loginctl", cependant, cela fait toujours partie de votre session d'origine, vous vous êtes connecté à l'origine. Vous pouvez le vérifier en appelant "loginctl status" sur l'ID de la session d'origine (que vous pouvez voir via echo $ XDG_SESSION_ID)