È necessario un riavvio per aggiornare le autorizzazioni dopo aver aggiunto un utente a un nuovo gruppo?

Sul server Ubuntu, ho notato più di una volta che dopo aver aggiunto un utente a un gruppo quell'utente non ha i permessi di gruppo fino a quando non riavvio il sistema. Per esempio:

L'utente "hudson" necessita dell'autorizzazione per leggere la directory "root: shadow / etc / shadow". Quindi aggiungo hudson al gruppo shadow. Hudson non riesce ancora a leggere. Quindi, 'sudo shutdown -h -r now' e quando il sistema riappare, l'utente hudson può leggere.

È necessario un riavvio o esiste un modo migliore per ottenere le autorizzazioni applicate dopo aver aggiunto l'utente al gruppo?

Stavo cercando una soluzione, mi sono imbattuto in questo post e poi ho trovato uno!

Pensavo di offrire davvero una soluzione in modo che altri possano trarne beneficio. Entrare e uscire è così 1995.

Preso da:

https://arkaitzj.wordpress.com/2010/03/08/linux-add-user-to-a-group-without-logout/

Quindi, se hai bisogno di ottenere le autorizzazioni per il cdromgruppo, hai appena aggiunto il tuo utente a:

newgrp cdrom 

per esempio

Quindi i passaggi sarebbero:

#adduser my_user cdrom

e poi

$newgrp cdrom

Ho confermato che funziona.

Un semplice $groupscontrollo dalla CLI indica che l'utente è nel gruppo. E una rapida esecuzione con i privilegi necessari da quel gruppo funziona.

Non c'è bisogno di uccidere Windows e accedere e disconnettersi! Spero che aiuti gli altri!

Informazioni aggiuntive (basate sull'utile commento di jytou): "[Questa] soluzione funzionerà solo per la shell aperta corrente. Se hai un'altra shell aperta, dovrai utilizzare lo stesso comando per tenere conto delle modifiche."

Quando si aggiunge un utente a un nuovo gruppo, l'utente deve disconnettersi e riconnettersi affinché abbia effetto. Mentre un riavvio lo farà, non dovrebbe essere richiesto.

L'aggiunta di un utente a un gruppo non ha effetto sugli utenti attualmente connessi.

Nel caso di un demone, è necessario riavviarlo per applicare nuovi gruppi.

Inoltre, riavviare il demone usando un'opzione nel demone stesso non funzionerà poiché erediterà l'ambiente corrente.

Il modo più semplice per farlo funzionare è fermare completamente il demone e riavviarlo, come in ..

/etc/init.d/foo stop ; /etc/init.d/foo start

che è molto più semplice, puoi controllare il tuo attuale livello di accesso digitando:

id

per ricaricare i tuoi gruppi devi solo:

su - $USER

dopo quel controllo di nuovo il livello di accesso:

id

e vedrai che il nuovo gruppo è ora attivo.

C'è una diversa modalità di errore che dovrebbe essere affrontata anche qui.

Se l'amministratore si è aggiornato /etc/groupma non è riuscito ad aggiornarlo /etc/gshadow(sui sistemi che hanno questa impostazione), disconnettersi e riconnettersi non verrà assegnato al nuovo gruppo.

Confusamente, groupsvi mostrerà il vero, situazione attuale, mentre idsarà in modo non corretto la stampa di uscita che indica che si è propriamente un membro del gruppo.

tripleee@vbvntv$ groups
tripleee

tripleee@vbvntv$ id
uid=1234(tripleee) gid=1234(tripleee) groups=1234(tripleee),4(adm)

tripleee@vbvntv$ ls -l /var/log/mail.log
-rw-r----- 1 root adm 15728 May 26 14:26 /var/log/mail.log

tripleee@vbvntv$ tail /var/log/mail.log
tail: cannot open `/var/log/mail.log' for reading: Permission denied

Non posso utilizzarlo newgrpperché richiede una password e non ho una password, ma solo l'autenticazione con chiave pubblica SSH.

La soluzione sarebbe che l'amministratore ripristini la modifica manuale di /etc/groupse poi lo faccia di nuovo con sudo gpasswd -a tripleee adm; o in alternativa, utilizzare grpconvper unire le modifiche (che ho raccolto da /server//a/389719/98333 )