Perché il sistema ha /etc/sudoers.d? Come dovrei modificarlo?

L'ultima volta, ho chiesto informazioni sul rischio di questi (in / etc / sudoers):

    user_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
    %group_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

Mentre pensavo a questo problema, ho trovato la directory /etc/sudoers.d . I file nella directory dovrebbero avere funzioni simili a / etc / sudoers (nel senso che gli script sopra sono ancora problematici anche in /etc/sudoers.d), e comunque un articolo dice che non dovremmo usare la directory perché non possiamo usare visudoper modificare i file in esso. Cioè, perdiamo il diritto di utilizzare sudose commettiamo un errore nella directory.

Se questo è vero, perché abbiamo /etc/sudoers.d ? Oppure abbiamo un buon modo per modificare i file in /etc/sudoers.d ?

Le modifiche apportate ai file /etc/sudoers.drimangono attive se si aggiorna il sistema. Ciò può impedire blocchi dell'utente quando il sistema viene aggiornato. Ubuntu tende ad apprezzare questo comportamento. Anche altre distribuzioni utilizzano questo layout.

È stata la mia esperienza che le regole sui file in questa directory sono più vaghe che per /etc/sudoers. Questo ha incluso:

• Gli errori nel file non hanno causato errori sudo. Tuttavia, il file è stato ignorato.
• Le regole di autorizzazione sembrano meno rigide. Consente al gruppo applicabile o ad altri di leggere il file. Non credo che sia stato possibile con /etc/sudoers. Le autorizzazioni di scrittura devono essere limitate rootper mantenere la sicurezza. L'attuale versione Ubuntu di sudo consente autorizzazioni di lettura per gruppi o altro. (Questa funzionalità consente di controllare l'accesso sudo utilizzando senza richiedere l'accesso root.)

Il visudocomando predefinito è solo /etc/sudoers. Modificherà e verificherà qualsiasi file specificato con l' -fopzione. Uso questa funzionalità per modificare i file che verranno installati automaticamente come /etc/sudoerso in /etc/sudoders.d. Tuttavia, non è possibile trovare definizioni da altri file. È meglio rendere il file indipendente.

La possibilità di disporre di file autonomi rende semplice per un'applicazione abilitare la sudofunzionalità durante l'installazione e rimuoverli quando non è installato. Anche gli strumenti di configurazione automatizzata possono utilizzare questa funzionalità.

Ho usato questa capacità per isolare le modifiche necessarie per consentire l'accesso a gruppi di utenti specifici su sistemi specifici.

Sì, puoi usare visudoper modificare quei file. Tutto quello che devi fare è specificare il nome del file che vuoi modificare con l' -fopzione. Per esempio:

visudo -f /etc/sudoers.d/somefilename

Oppure, se necessario:

sudo visudo -f /etc/sudoers.d/somefilename

Documentazione

Da man visudo:

-f sudoers
Specifica e alterna la posizione del file sudoers. Con questa opzione visudo modificherà (o selezionerà) il file sudoers di tua scelta, invece che quello predefinito, / etc / sudoers. Il file di blocco utilizzato è il file sudoers specificato con ".tmp" aggiunto ad esso. Solo in modalità di solo controllo, l'argomento di -f può essere "-", indicando che i sudoer verranno letti dall'input standard.

In sintesi:

1. Sintassi: entrambi visudoed visudo -f eseguono lo stesso controllo della sintassi .

2. Autorizzazioni / Proprietà: come funzionalità aggiunta per aiutare l'amministrazione di sistemi di grandi dimensioni , i file modificati in visudo -fnon vengono controllati per la proprietà o le autorizzazioni: ciò consente il controllo della sintassi di un file offline o come parte di un sistema di controllo di revisione.

Perché usare /etc/sudoers.d/

In genere /etc/sudoersè sotto il controllo del gestore dei pacchetti della tua distribuzione. Se hai apportato modifiche a quel file e il gestore pacchetti desidera aggiornarlo, dovrai ispezionare manualmente le modifiche e approvare il modo in cui vengono unite nella nuova versione. Inserendo le modifiche locali in un file nella /etc/sudoers.d/directory, si evita questo passaggio manuale e gli aggiornamenti possono procedere automaticamente.

Quando sudoignora un file /etc/sudoers?

Se il tuo /etc/sudoersfile contiene la riga:

#includedir /etc/sudoers.d

quindi sudoleggerà i file nella directory /etc/sudoers.d.

Le eccezioni sono:

1. File i cui nomi finiscono ~
2. File i cui nomi contengono un .carattere

Questo viene fatto (a) per comodità dei gestori di pacchetti e anche (b) in modo che i file di backup dagli editor vengano ignorati.

perché abbiamo /etc/sudoers.d?

Perché è più facile per gli strumenti automatizzati (come Chef o Puppet) rilasciare singoli file in questa directory, piuttosto che apportare modifiche /etc/sudoers, che potrebbero essere fragili.

I file in /etc/sudoers.dsono (in effetti) concatenati. Vedrai diverse altre istanze di questo modello in /etc, come /etc/cron.de /etc/logrotate.d.

Un altro vantaggio dell'utilizzo visudo -fcome indicato in alcune risposte è che esiste un'opzione corrispondente -co --checkche verifica che non si disponga di informazioni non valide in un file sudoers.d o in qualsiasi altro file che si desidera inserire in sudoers.d. Questo è DAVVERO utile nei casi menzionati con strumenti automatizzati, come è possibile eseguire ad es

sudo visudo -c -q -f /home/myuser/mysudoers && \
sudo chmod 600 /home/myuser/mysudoers && \
sudo cp /home/myuser/mysudoers /etc/sudoers.d/mysudoers

Questo controlla silenziosamente il file (nessun output dovuto a -q) e solo se NON restituisce un errore (exit 1 significa un file sudoers non valido), lo copierà in sudoers.d, in questo modo puoi creare il file e lavoraci su senza doverlo sudo visudo -f /etc/sudoers.d/myfilecorreggere la prima volta (usare deve riuscire o scarta il contenuto se non lo aggiusti).

Inoltre, una parola di cautela riguardo a queste affermazioni dalle altre risposte.

È stata la mia esperienza che le regole sui file in questa directory sono più allentate rispetto a / etc / sudoers. Questo ha incluso:

Gli errori nel file non hanno causato errori sudo. Tuttavia, il file è stato ignorato. Le regole di autorizzazione sembrano meno rigide. Autorizzo il gruppo applicabile a leggere il file. Non credo che sia possibile con / etc / sudo.

I file in /etc/sudoers.d sono tenuti ad aderire alla stessa sintassi di / etc / sudoers, perché sotto le copertine il sistema concatena semplicemente tutti i file con l'ultimo in "vincente" se ci sono più voci per lo stesso impostazione singolare.

Se i permessi sono orribilmente errati (scrivibili dal mondo) sui file in /etc/sudoers.d/, allora vengono ignorati, questo potrebbe essere ciò che ha fatto sì che i file non validi vengano trascurati, altrimenti puoi seriamente rompere il sudocomando avendo un sudoers non valido. d file con le autorizzazioni corrette.

Puoi consentire ai file sudoers di essere leggibili in tutto il mondo, se accetti accidentalmente "altro" l'autorizzazione in scrittura che devi eseguire sudo come altro utente o da un terminale root esegui questo comando. Questo può anche rompersi se il file è di proprietà di qualcuno diverso da root: root.

sudo chmod 644 /etc/sudoers.d/mysudoers
sudo chown root:root /etc/sudoers.d/mysudoers

Ho appena confermato che se corro chmod o+w /etc/sudoers.d/vagrantnon riesco più a fare il sudo come utente vagabondo, mi richiede la mia password e poi fallisce.

Quando ho corso sudo -lper visualizzare le autorizzazioni del comando applicato come un altro utente sudo valido, ho anche ricevuto un avviso sulle autorizzazioni del file. Questo è lo stesso comando che ho usato per confermare che l'utente 'vagabondo' ha perso sudo quando ho applicato le o+wautorizzazioni al file dando all'utente le autorizzazioni sudo.

Solo una breve aggiunta a qualsiasi risposta generale ... nessuna delle altre risposte risolto il mio problema, che era l'ordine che conta.

Se le tue linee funzionano su sudoers ma non sudoers.d, prova a spostare #include in giro, o cambiando l'ordine dei tuoi file sudoers.d (prefissando un numero). Sembra che la cosa più specifica dovrebbe essere la prima nel file.

Ho avuto qualcosa di simile:

somebody ALL=(ALL): somecommand
somebody ALL=(someoneelse) NOPASSWD: somecommand

E il secondo non ha avuto effetto perché il primo era già abbinato. NOPASSWD non è una condizione, ma un modo per modificare l'azione.

E non era ovvio perché non era in un singolo file, a causa della directory sudoers.d.