forzare la richiesta di una password per l'installazione dei pacchetti

Fedora Linux Configurazione
#1

Buona sera a tutti ragazzi, oggi mi sono accorto per puro caso che nel momento in cui digito un comando da terminale che non è installato, mi permette qualora lo trovasse di installarlo automaticamente e senza richiedere la password. Questa cosa mi ha sconvolto, anche perché, facendo più attenzione, questa cosa succede anche quando installo gli aggiornamenti da gnome Software.
Pertanto mi chiedo, è possibile forzare ogni qual volta si installano gli aggiornamenti da gnome software o attraverso la funzione che ho scoperto oggi, forzare di richiedere la password di amministratore?

Spero di essere stato chiaro, vi auguro buon fine settimana!

#2

No, non credo sia possibile ed è meglio che sia così. Dnf o una qualunque GUI tipo Apper abbisognano di quella autorizzazione. Non siamo sotto M$ Windows dove chiunque può installare quello che vuole e dove non c’è distinzione tra amministratore di sistema e utente generico. Qui le cose sono distinte: amministratore di sistema o utente. Pensa che un tempo tutte le distribuzioni Linux permettevano di avere il root sotto XWindow, ora non più. Perchè è stata abolita questa possibilità? Perchè XWindow opera in remoto, anche attraverso un collegamento internet. E se qualcuno intercettava quel traffico poteva ottenere la password di root, quindi i pericoli si dovevano evitare. Lo so, è dura, ma questa è la differenza tra un *nix e M$ Windows…

#3

@d68qdq8dq Mi pare che il problema del nostro giupardeb sia opposto: vorrebbe che fosse richiesta la password, ma nel suo sistema non è così (ho redatto il titolo perché fosse spero più chiaro)

Se attualmente installa senza chiedere password e senza ricorrere a sudo temo che si stia usando l’utente root per tutto (cosa sconsigliata), per cui procederei alla creazione di un utente per l’ordinaria amministrazione.

Se attualmente installa tutto usando sudo ma senza chiedere mai una password,
controllerei innanzitutto se (come credo) l’utente “normale” con cui è loggato appartiene al gruppo wheel

$ id

se la password non è impostata, la aggiornerei

$ passwd

quindi controllerei le impostazioni dei sudoer

$ sudo visudo

e controllerei che il rigo

# %wheel        ALL=(ALL)       NOPASSWD: ALL

sia commentato (abbia, cioè, quel simbolo cancelletto a inizio riga)
controllerei altre occorrenze di NOPASSWD nel file ed eventualmente di timestamp_timeout (per impostazione predefinita il timeout è cinque minuti, per cui non viene più richiesta la password se l’ultimo comando dato con sudo è stato inviato entro questa finestra temporale)

#4

Innanzitutto grazie per le risposte.

@tempus prima di procedere con i tuoi consigli, provo a chiarire ulteriormente la situazione postando la seguente immagine:
https://postimg.cc/Yv7nmC6chttps://i.postimg.cc/Yv7nmC6c/Screenshot-from-2019-05-06-09-08-57.png

come puoi vedere se provo a instalalre manualmente nano con dnf e senza permessi di root, mi ritorna l’errore. Ma se provo a lanciare nano, non trovando il pacchetto mi consiglia di installarlo e fa ciò senza richiedere la password.
Non credi sia un problema?

#5

Ricordo che è sempre opportuno e preferibile postare i comandi dati utilizzati il tag code

[code]così[/code]

Quello è un “helper” di PackageKit; nella sua configurazione predefinita, “PackageKit-command-not-found” (questo il nome del pacchetto che offre questa funzionalità) ricerca e installa pacchetti per utenti appartenenti al gruppo %wheel; altri package manager grafici potrebbero offrire questa funzionalità. Personalmente, non adotto package manager grafici né uso PackageKit, e la mia personalissima opinione è che sia un errore permettere per impostazione predefinita l’installazione senza richiedere la password per il solo fatto che l’utente richiedente appartiene al gruppo %wheel, ma tant’è. L’elevazione dei privilegi necessari all’operazione avviene “per design” grazie a polkit (al cui manuale rimando); l’agente di autenticazione è avviato al login grafico.
Alternative possibili:

  • abilitare un account root e rimuovere l’utente abituale dal gruppo %wheel;
  • rimuovere PackageKit-command-not-found (ma sarebbe sempre possibile usare pkcon se PackageKit è installato; per esempio, dando
$ pkcon install nano

);

  • scalzare la regola contenuta in /etc/polkit-1/rules.d/50-default.rules forzando la richiesta della password per l’account root (se esitente e configurato) anziché quella per l’utente abituale appartenente al gruppo wheel
  • scalzare la regola contenuta in /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules (file installato da PackageKit), rimuovendo la facoltà per PackageKit di assumere senza autenticazione i privilegi propri dell’utente se appartiene al gruppo wheel attraverso polkit ogni qual volta packagekit è invocato, inibendo quel return polkit.Result.YES; contenuto in

polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.package-install" && subject.active == true && subject.local == true && subject.isInGroup("wheel")) { return polkit.Result.YES; } });

  • rimuovere PackageKit con tutto ciò che ne consegue, e usare solo dnf
#6

Sono d’accordissimo con te, pertanto ho eliminato PackageKit con tutto ciò che ne consegue.
Ho due domande adesso:
conviene eliminare il mio utente dal gruppo wheel?
conviene eliminare gnome software e usare solo dnf? Installo i pacchetti attraverso dnf, mi viene molto più comodo

#7

Alcuni sono abituati a tenere due account separati (account root e account ordinario), molti rivendicano l’utilità dell’utente amministratore, specialmente in terminali che di fatto hanno un singolo utente/seat.
Se già non usi PackageKit con annessi e connessi, la soluzione preferibile sembrerebbe rimuovere ciò che è inutile nel tuo uso abituale: se non fosse che PackageKit ha una certa quantità di dipendenze in tutti gli ambienti grafici (non solo GNOME). Puoi senz’altro rimuovere PackageKit-command-not-found ma rimuovere tutto PackageKit trascinerà una certa quantità di dipendenze, specialmente in GNOME.

La soluzione preferibile perché più a “basso impatto” sia per il tuo attuale setup sia per il setup predefinito del SO credo sia semplicemente scalzare la regola contenuta in /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules.
Editare direttamente la regola in questione nel file installato da PackageKit non assicura la sopravvivenza della modifica a successivi aggiornamenti. Poiché polkit traversa /etc e /usr e s’arresta alla prima regola che fa match (rinvio alla https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html per i dettagli), andremo a duplicare la regola incriminata , posizionandola in /etc, deputato a ricevere configurazioni specifiche di sistema.

$ sudo cp /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules /etc/polkit-1/rules.d/ $ sudo sed -i 's/polkit.Result.YES/polkit.Result.AUTH_ADMIN/' /etc/polkit-1/rules.d/org.freedesktop.packagekit.rules $ sudo chmod o+r /etc/polkit-1/rules.d/org.freedesktop.packagekit.rules $ sudo chcon system_u:object_r:etc_t:s0 /etc/polkit-1/rules.d/org.freedesktop.packagekit.rules
dovrebbe essere sufficiente.

#8

ma se semplicemente rimuovo PackageKit-command-not-found e lascio tutto come di default? Credo che si dovrebbe risolvere il mio problema ma allo stesso tempo non faccio molto “danno” a livello di dipendenze

#9

Ho provato a rimuovere PackageKit. Gnome sembra continuare a funzionare correttamente, ma KDE viene rimosso per dipendenze. PackageKit-command-not-found non ce l’ho neppure installato, quindi non credo che ci siano problemi a rimuoverlo.

#10

Resta pkcon, un utente locale appartenente al gruppo wheel sarebbe sempre in grado di dare un

$ pkcon install nano

senza inserire password.

Grazie per la conferma, non ho controllato recentemente le dipendenze trascinate in ambiente GNOME.

È possibile rimuovere PackageKit senza troppi strascichi con

$ sudo dnf --setopt=clean_requirements_on_remove=0 remove PackageKit PackageKit-glib

così da rimuovere solo plasma-discover come dipendenze. Se si rimuove anche PackageKit-Qt5 si vanno a rimuovere elementi rilevanti del DE; tuttavia basta rimuovere il solo pacchetto PackageKit per rimuovere pkcon e regola polkit.