565 votes

Recharger les affectations de groupe d'un utilisateur Linux sans se déconnecter

Lors de l'affectation de la liste de groupes secondaires d'un utilisateur en utilisant :

# usermod -G <grouplist> <user>

est-il possible de forcer cette affectation de groupe à prendre effet sans déconnecter toutes les sessions en cours ?

Cela serait très utile dans la situation où une Écran existe avec de nombreux shells en cours d'exécution, car la session entière doit être détruite pour que l'affectation de groupe prenne effet.

Je pense que je peux changer le groupe primaire de l'utilisateur dans un Shell en cours d'exécution en utilisant la commande newgrp commande - existe-t-il une alternative qui fonctionnerait pour les groupes secondaires ?

Idéalement, je voudrais quelque chose qui prenne effet dans chaque Shell sans être exécuté manuellement dans chacun d'eux, mais à défaut, peut-être un moyen de forcer Screen à exécuter la même commande dans chacun.

0 votes

Je sais qu'au moins pour certains gestionnaires de fenêtres/sessions, il est possible de le faire de telle sorte que la session récupère le nouveau groupe et qu'il soit disponible pour tout nouveau processus lancé à partir des menus, des boutons du panneau ou autre. Je viens juste de venir ici pour retrouver cette information, donc je ne peux pas dire maintenant comment faire, et c'est probablement spécifique au gestionnaire de fenêtres.

0voto

Patrick Points 101

J'avais besoin de faire cela dans un Shell Shell (Shell ajoute l'utilisateur actuel à un groupe, exécute les commandes ultérieures qui nécessitent cette appartenance au groupe). Le site newgrp est fragile dans la mesure où elle ne peut exécuter qu'une nouvelle Shell plutôt qu'une commande arbitraire (je veux réexécuter la Shell Shell actuelle avec les arguments de ligne de commande originaux).

Voici ma solution, qui utilise beaucoup de bash-ismes : (notez que le script qui l'entoure a besoin d'une sorte de branche pour ne lancer cette fonction que si le groupe requis n'est pas actuellement actif) :

(note : le script implique qu'il a été exécuté sudo adduser $user docker ce qui signifie qu'il pourrait aussi simplement exécuter sudo docker partout au lieu de docker mais cela n'était pas souhaitable dans ce cas)

# save these for later
ORIGINAL_ARGS=("$@")

# This function is a little insane. The problem is this: user running
# this script is not a member of docker group, but used 'sudo' to add
# themselves to group. Without logging out and back in, the only way
# to gain access to that group is via the 'newgrp' command, which
# unfortunately starts a new shell rather than an arbitrary command...
#
# Also, we're going to newgrp twice: first to add the new group and
# again to restore the original group (but the new group remains in
# the 'groups' output).
#
# So this horrendous hack dups stdin to fd3 for later. Then runs
# 'newgrp' piping in a script that runs 'newgrp' a second time, piping
# in another script that restores stdin from fd3 and execs the
# original command...
restart-newgrp-newgrp() {
  # dup original stdin to fd3
  exec 3<&0

  local group="$1"
  local command="$0"
  local arg
  for arg in "${ORIGINAL_ARGS[@]}"; do
    printf -v command "%s %q" "$command" "$arg"
  done

  # restore original stdin from fd3; also replace any single-quote in
  # command with '"'"' to embed it in a single-quoted string
  local script
  printf -v script "exec newgrp %q <<<'exec <&3-; exec %s'" "$(id -gn)" "${command//\'/\'\"\'\"\'}"

  exec newgrp "$group" <<<"$script"
}

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X