Pagina 1 di 1

[RISOLTO] FEDORA (RH) annacqua /bin/su

Inviato: sab 21 nov 2009, 15:06
da Mario Vanoni
https://bugzilla.redhat.com/show_bug.cgi?id=534047#c9

Codice: Seleziona tutto

Comment #1 From  Richard Hughes  2009-11-17 07:03:03 EDT  -------

Can you please try the build here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=141430 -- thanks.  

------- Comment #2 From Need Real Name 2009-11-18 07:47:19 EDT -------

Seems to work: but why am I not getting a root password prompt?  

------- Comment #3 From Richard Hughes 2009-11-18 08:16:50 EDT -------

(In reply to comment #2)
> why am I not getting a root password prompt?  

PackageKit allows you to install signed content from signed repositories
without a password by default. It only asks you to authenticate if anything is
unsigned or the signatures are wrong.  

------- Comment #4 From Rahul Sundaram 2009-11-18 12:31:44 EDT -------

Richard Hughes,

It would be have useful if you had added a note to the release notes on this
along with the rationale. Can you provide the precise steps to revert this?  I
think we will a release notes update covering the details. Thanks.  

------- Comment #5 From Need Real Name 2009-11-18 12:48:01 EDT -------

Please could this be reversed, the default being that the root user gets to
install software, and the users as well, if the root user wishes them to.

This is really a *major* change that is precise opposite of the way *NIX has
always worked.  

------- Comment #6 From Simo Sorce 2009-11-18 13:53:09 EDT -------

Please set it back to the way it was in F-11.

This default is insecure and it is also hard to find out how to change it on a
default install.

This is not a good policy, doesn't help anyone and is a step in the wrong
direction.  

------- Comment #7 From TK009 2009-11-18 14:04:15 EDT -------

Please revert this change.
Setting FutureFeature
Setting Severity High

TK009
---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers  

------- Comment #8 From Richard Hughes 2009-11-18 14:05:35 EDT -------

(In reply to comment #6)
> This default is insecure and it is also hard to find out how to change it on a
> default install.

It's not insecure. We've had the mechanism checked. The default policy may not
be to your taste, but this is the "desktop" spin, not the "server" spin.

> This is not a good policy, doesn't help anyone and is a step in the wrong
> direction.  

You missed the "in my opinion" line in your reply.  

------- Comment #9 From Richard Hughes 2009-11-18 14:07:45 EDT -------

(In reply to comment #5)
> This is really a *major* change that is precise opposite of the way *NIX has
> always worked.  

I don't particularly care how UNIX has always worked. Looking at the use-cases
and the things people are trying to do this seemed the best default. Admins can
trivially change the default on machines if they wish.

Richard.  
Richard Hughes,
il Maintainer di Paketmanagers PackageKit presso Fedora
parla chiaro come la pensa.

Progresso alla Redmond?

UPDATE:
http://docs.fedoraproject.org/release-n ... urity.html

Re: FEDORA (RH) annacqua /bin/su

Inviato: sab 21 nov 2009, 15:22
da neongen
The default policy may not
be to your taste, but this is the "desktop" spin, not the "server" spin.
...
Admins can
trivially change the default on machines if they wish.
considerando che installa senza password solo i pacchetti firmati non ci vedo nulla di male

Re: FEDORA (RH) annacqua /bin/su

Inviato: sab 21 nov 2009, 15:56
da sir_alex
In effetti, su una macchina desktop, con tipicamente un solo utente che ci lavora, il dover inserire la password per effettuare alcuni task non ha molto senso.
Certo, se ti bucano la macchina non hanno bisogno di fare privilege escalation per installare roba, sarebbe interessante sapere se viene richiesta per rimuovere cose (che sarebbe allora sì veramente grave), stabilito che i pacchetti devono comunque essere firmati correttamente, quindi un malevolo non può installarsi la sua versione rootkittata di un software al volo...

Re: FEDORA (RH) annacqua /bin/su

Inviato: sab 21 nov 2009, 16:03
da navajo
Io invece non sono d' accordo.
Un sistema GNU/linux viene scelto anche per la sua identità e prerogative. Il dover essere ROOT o super utente, è una di queste. Non dover metter su la password di root e anacquare il sistema come dice mario, non significa renderlo più facile da gestire. In fondo, usando sudo, questo avviene già, infatti una volta data la password, e lavorando comunque con la stessa shell, puoi dare sudo -S ogni volta che vuoi.
Poi questa è comunque la mia piccola e umilissima opinione.

Re: FEDORA (RH) annacqua /bin/su

Inviato: sab 21 nov 2009, 16:12
da Mario Vanoni
https://www.redhat.com/archives/fedora- ... 01445.html

Codice: Seleziona tutto

Executive summary
=================

We'll make an update to the F12 PackageKit, so that the root password is
required to install packages.
Quindi viene tolto, meno male.

Re: FEDORA (RH) annacqua /bin/su

Inviato: sab 21 nov 2009, 16:14
da navajo
Mario Vanoni ha scritto:https://www.redhat.com/archives/fedora- ... 01445.html

Codice: Seleziona tutto

Executive summary
=================

We'll make an update to the F12 PackageKit, so that the root password is
required to install packages.
Quindi viene tolto, meno male.
Tiriamo un sospiro di sollievo :)

Re: FEDORA (RH) annacqua /bin/su

Inviato: sab 21 nov 2009, 22:50
da phobos3576
Mario Vanoni ha scritto:https://www.redhat.com/archives/fedora- ... 01445.html

Codice: Seleziona tutto

Executive summary
=================

We'll make an update to the F12 PackageKit, so that the root password is
required to install packages.
Quindi viene tolto, meno male.
Meno male sino a un certo punto.

I responsabili di Fedora, oltre ad aver aggiunto quella funzionalità senza avvisare nessuno, hanno pure cercato di chiudere violentemente quella discussione; in seguito, altri utenti l'hanno riaperta altrettanto violentemente affermando che Fedora non aveva nessun diritto di comportarsi in quel modo.

Solo dopo che molti utenti hanno esposto in modo chiaro i rischi a cui si andava incontro con quella follia, gli sviluppatori di Fedora hanno fatto marcia indietro.

Ci si rende conto così che anche nel mondo Linux ci sono questi sciagurati, irresponsabili; come quell'altro pazzo che su Debian si era messo a commentare una riga nel sorgente di OpenSSL, ritenendola inutile, ed aveva così compromesso il generatore di numeri casuali con una conseguente falla che, per fortuna, nessuno è riuscito a sfruttare (speriamo).
Ma se uno si mette a commentare una riga di un sorgente senza neppure sapere a cosa serva, che ci sta a fare in Debian?

Quella notizia purtroppo fece il giro del mondo e nelle comunità Windows si rise di Linux per mesi.

Anche della vicenda Fedora adesso ne parlano tutti; su Slashdot si leggono commenti del tipo: "ho bisogno di un sistema sicuro: mi sa che passo a Windows7"!

Mi auguro solo che il buon Pat prenda le distanze da queste iniziative folli.
Tra l'altro, si tratta di una vicenda che chiama in causa anche PolicyKit; proprio in quella discussione su Fedora, molti utenti hanno chiesto delucidazioini in merito alla gestione dei permessi da parte di quel package.

Pat aveva rinunciato a KDE 4.3 sulla 13 proprio per PolicyKit; adesso è passato a KDE 4.3 sulla current, ma di PolicyKit neppure l'ombra.
Forse a Pat sono venuti dei dubbi?

Re: FEDORA (RH) annacqua /bin/su

Inviato: dom 22 nov 2009, 11:44
da ildiama
phobos3576 ha scritto:Mi auguro solo che il buon Pat prenda le distanze da queste iniziative folli.
Tra l'altro, si tratta di una vicenda che chiama in causa anche PolicyKit; proprio in quella discussione su Fedora, molti utenti hanno chiesto delucidazioini in merito alla gestione dei permessi da parte di quel package.

Pat aveva rinunciato a KDE 4.3 sulla 13 proprio per PolicyKit; adesso è passato a KDE 4.3 sulla current, ma di PolicyKit neppure l'ombra.
Forse a Pat sono venuti dei dubbi?
No, io penso che gli attuali pacchetti della current siano solo ad uso e consumo degli utenti della 13.0. Un upgrade "regalato" di KDE senza intaccare la compatibilità. Altrimenti avrebbe upgradato prima gcc, glibc, X che come si vede non sono ancora stati toccati.