policykit

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

policykit

Messaggio da masalapianta »

Ho ricevuto in pm una richiesta di chiarimento su quanto in oggetto, inoltre ho letto qua e la cose che denotavano una scarsa comprensione del suddetto framework, quindi scrivo questa risposta in pubblico a beneficio di tutti:

Policykit e' una sorta di implementazione di mandatory access control in user space
pensato per le componenti di un desktop environment; che significa? significa che
quando un'applicazione di un DE (che gira completamente con utenza non privilegiata)
deve eseguire un'operazione privilegiata, contatta tramite un bus (di solito dbus)
una serie di applicazioni privilegiate, le quali (basandosi sull'identita' del richiedente,
l'azione richiesta e l'oggetto su cui intraprendere tale azione; quindi ad esempio
il richiedente e' il processo pippo, l'azione e' il mount di un dispositivo e l'oggetto
e' il dispositivo da montare) decidono se eseguire tale operazione e, in caso affermativo,
la eseguono, sgravando completamente il richiedente da questo compito (che non potrebbe
eseguire in quanto non ne ha i privilegi)

Architettura

ogni applicazione, che necessita di effettuare azioni che richiedano i permessi di root,
contatta hal (tramite dbus), il quale identifica il richiedente tramite consolekit (in base
a uid, pid e tipo di sessione, se attiva/non-attiva, remota/locale); a questo punto,
basandosi su richiedente, azione ed oggetto, hal tramite la libpolkit (una libreria che
permette di mappare azioni, oggetti, ecc.. e prendere decisioni su chi puo' fare cosa
su quale oggetto, basandosi sulle entry che trova nel db delle autorizzazioni) decide cosa
fare tra le seguenti due cose:

1) eseguire l'azione richiesta (in caso che nella configurazione di policykit non sia richiesta
autenticazione per eseguire quell'azione su quell'oggetto da parte del richiedente)

2) informare il richiedente che necessita di essere autenticato affinche' possa
essere eseguita l'azione richiesta; in tal caso il richiedente contatta un agent
di autenticazione (un processo non privilegiato), il quale, tramite la
libpolkit-grant (una libreria di autenticazione setuid che fa uso di pam e un helper
che gode dei privilegi di root tramite setgid) che verifica le credenziali e,
in caso positivo, tramite l'helper privilegiato, scrive una entry nel database
delle autorizzazioni (un db in cui viene mappato chi puo' fare cosa su quale oggetto),
per scrivere nel quale servono i privilegi di root (tale db e' lo stesso che utilizza
hal, tramite libpolkit, per decidere quali azioni intraprendere).

La suddetta entry specifica una delle seguenti 3 cose:

- quel dato richiedente (identificato dal pid e dallo
start time del processo) puo' eseguire quella data operazione su quel dato oggetto
(in virtu' dell'autenticazione effettuata)
- tutti i processi che si trovano nella stessa sessione desktop del richiedente
sono autorizzati ad eseguire quella data operazione su quel dato oggetto (in virtu'
dell'autenticazione effettuata)
- tutti i processi che girano con il medesimo uid del richiedente sono autorizzati ad
eseguire quella data operazione su quel dato oggetto (in virtu'dell'autenticazione
effettuata) e la suddetta entry nel db delle autorizzazioni non viene eliminata
al reboot del sistema

dopodiche' comunica al richiedente l'esito dell'autenticazione; in caso di esito positivo
il richiedente ricontatta hal e chiede di eseguire l'azione che gli aveva chiesto in
precedenza, hal verifica nel db delle autorizzazioni che il richiedente sia abilitato
(stavolta lo e' in virtu' della entry inserita dall'helper di cui sopra) ed esegue
l'azione richiesta



a grandi linee (alcuni aspetti li ho semplificato un po a favore della comprensione) questa
e' la struttura e il funzionamento di policykit.


Veniamo alle considerazioni:


Vantaggi

- permette un tipo di controllo piu' granulare rispetto a sistemi basati su gruppo di
appartenenza o su sessione
- tutto il codice privilegiato viene centralizzato (a differenza di meccanismi come setuid o sudo
che necessitano di dare privilegi ad ogni singolo processo che li richiede) quindi, in
configurazioni non banali, si eseguira' meno codice privilegiato; senza contare tutte
le positive implicazioni relative all'auditing del codice che necessita privilegi
- molto piu' semplice da configurare e da utilizzare rispetto a soluzioni in kernel space tipo
selinux

Svantaggi

- tutti i flussi di comunicazione, tra processi privilegiati e non, introducono potenziali buchi
di sicurezza
- molto meno robusto dal punto di vista della sicurezza rispetto a soluzioni in kernel space
tipo selinux (e meno sicuro anche rispetto all'amministrazione del sistema via cli con i tool
standard)
- richiede applicazioni scritte appositamente per supportare tale framework
- e' fortemente diseducativo per l'utente (vedere la parte "Considerazioni personali")


Considerazioni personali

In un contesto di sistemi che facciano uso di desktop environment complessi (quali gnome o kde)
e laddove l'utente non sia anche l'amministratore della macchina (in tal caso l'utente possiede
anche la password di root e quindi l'uso di policykit ha una valenza di forma piu' che di sostanza,
servendo unicamente a evitare di usare sistemi di gestione del sistema basati sulla cli),
policykit ha molto senso, in quanto permette di definire in maniera abbastanza granulare politiche
di sicurezza per N utenti, in maniera semplice e _relativamente_ sicura (rispetto a sistemi come
sudo).
Viceversa se parliamo di utenti che siano anche amministratori della propria macchina (il 99%
degli utenti home), policykit e', a mio avviso, una scelta pessima; lo e' per lo stesso motivo
per il quale lo sono tutte quelle cose che creano troppi layer d'astrazione che nascondono la
complessita' dell'ambiente sottostante; i motivi di questa affermazione li ho ripetuti decine
di volte, ma vediamo di fare un ripasso:

Chi sostiene la maggior semplicita' d'uso di sistemi complessi con piu' strati d'astrazione
sommati che nascondano all'utente finale il funzionamento del sistema, ha sempre anche usato
argomentazioni quali: "non tutti vogliono sapere come funziona un sistema ma molti lo vogliono
semplicemente usare", ok ma allora perche' se non funziona qualcosa non chiami un tecnico
specializzato piuttosto che metterci le mani tu? allora non vuoi solo essere un utente finale;
vuoi la strada semplice (non rendendoti conto che invece imbocchi quella difficile) e pensi
d'essere piu' furbo (quando in realta' sei solo piu' cretino perche' non perdi n tempo
all'inizio ma poi, sommando tutto il tempo perso dietro a problemi di cui non capivi un cavolo,
hai n+m tempo perso, con m che cresce ad ogni nuovo problema).

Quindi non prendiamoci per i fondelli con il discorso del "lui vuole solo usare quel software e
non vuole sapere altro", perche' non e' cosi', o almeno lo e' solo quando fa comodo.

Se veramente vuoi usare e basta senza saper nulla (esattamente come quando compri un'automobile
e se si rompe la porti dal meccanico/carroziere/gommista anziche' metterci le mani tu), allora
effettivamente e' piu' semplice da usare una distro con una UI molto astratta, ma se poi al
primo problema anziche' chiamare un tecnico (come faresti con qualsiasi altra cosa per la quale
vuoi essere solo un utilizzatore finale senza saper nulla) pretendi di metterci le mani tu, col
cavolo che e' piu' semplice.

Non esiste mai la via facile, in nessun caso; magari sembra facile e tu pensando di essere
furbo (quando in realta' dimostri solo d'esser cretino) credi di faticare meno, ma tutto quel
che ottieni e' farti il c**o a tarallo molto di piu' di chi ha preso la strada che a te sembrava
difficile.

L'unica via facile che esiste e' delegare la manutenzione ed essere realmente solo utlizzatori
finali; ma, se cosi' non e', la via piu' semplice e meno faticosa e' sempre quella con la curva
d'apprendimento piu' ripida che, una volta a regime, ti permette di risolvere qualunque problema
in pochi minuti.

il punto non e' se fai una certa operazione N o M volte al mese, ma se sei consapevole di come
funzioni quel che c'e' dietro quell'operazione; la "curva di apprendimento" di cui ho parlato
fino ad ora non e' un sacco tipo quello di babbo natale, pieno di nozioni tipo: "per fare questa
operazione fai prima questo, poi quello e poi quest'altro" (in tal caso il mio discorso non
avrebbe senso perche' ad ogni problema nuovo l'utente non saprebbe come risolvere e la curva
di apprendimento andrebbe su all'infinito); piuttosto e' una forma mentis, un modo di ragionare
che ti formi comprendendo come funziona intimamente il sistema che usi; questo ti permette di
affrontare problemi e risolverli anche quando il problema e' nuovo o quando non lo si affronta
da tanto tempo.

Ovviamente se si usano DE come gnome o kde (soprattutto quest'ultimo) che hanno una forte
integrazione con il sistema e con se stessi, anche se si e' amministratori della propria
macchina l'uso di policykit e' quasi d'obbligo.

N.B. un'obiezione che si potrebbe fare al suddetto discorso potrebbe essere: "non e' vero che
l'uso di policykit, nel caso in cui l'utente e' anche amministratore, ha una valenza di forma
piu' che di sostanza, perche' comunque, anche amministrando il sistema da cli, hai lo svantaggio
di dover essere root e di lanciare ogni tool da root (quindi la quantita' di codice che gira con
i massimi privilegi cresce, rispetto all'uso di un framework come policykit)", questo e' senza
dubbio vero, ma va considerato che i tool d'amministrazione di un sistema linux da cli, non sono
moltissimi, sono gli stessi da anni, e il loro codice ormai e' abbastanza stabile (dal punto
di vista della sicurezza); inoltre policykit spesso esegue con i massimi privilegi un bel malloppo
di codice (come ad esempio PackageKit) e non delle mere syscall (come selinux).

Avatar utente
navajo
Staff
Staff
Messaggi: 3884
Iscritto il: gio 8 gen 2004, 0:00
Nome Cognome: Massimiliano
Slackware: 13.37 (x86_64)
Kernel: 2.6.37.6
Desktop: KDE 4.7.0 (Alien)
Località: Roma

Re: policykit

Messaggio da navajo »

Mamma mia :D :D
meglio di così si muore. almeno abbiamo tutti un' idea un pochino più chiara della faccenda, e almeno io, cominicio a capire i dubbi di Pat.
Grazie Masala... :thumbright:

Avatar utente
Savius
Linux 3.x
Linux 3.x
Messaggi: 553
Iscritto il: gio 14 ago 2008, 13:45
Slackware: Slackware64 14.0
Kernel: 3.2.29-smp
Desktop: KDE 4.8.5
Località: Napoli

Re: policykit

Messaggio da Savius »

Grazie mille per il tuo post Masalapianta!!! :D
Ero tra quelli che non si capacitava del perché Pat avesse così tanta ostilità nei confronti delle PolicyKit! :D Però c'è una cosa che non condivido e che riguarda le tue considerazioni personali. Il compito di noi Informatici è quello di "astrarre" da problemi complessi soluzioni semplici in modo da riuscire a risolverli e comprenderli al meglio. Secondo il tuo modo di vedere le cose allora non dovremmo neanche usare dei linguaggi di alto livello ma programmare direttamente in assembler (giusto per dirne una) perché linguaggi come il C, Java eccetera ti "semplificano" la vita e fanno ciò che, in maniera estremamente più complessa, fanno anche linguaggi di basso livello. Io sono uno di quelli che vuole le cose semplici: vorrei ad esempio che esistesse qualcosa di meno complesso per creare pacchetti per Slackware invece di seguire tutte le procedure spiegate sul Wiki ma non le critico! Dico semplicemente che, per come sono fatto io, le cose devono essere semplici ed intuitive e ben vengano programmi che mi permettano di fare la stessa cosa ma con minor impiego di tempo e studio... Se riscontro un problema ALLORA mi studio il tutto e vedo come risolverlo ma di sicuro non mi lamento per la complessità che c'è dietro ad ogni cosa in apparenza semplice perché, se dovessimo scandagliare la totalità delle applicazioni esistenti, ci scontreremmo sicuramente con meccanismi molto complessi e che richiedono uno studio approfondito. :p

Ovviamente questo è il mio punto di vista eh! :D

Mario Vanoni
Iper Master
Iper Master
Messaggi: 3174
Iscritto il: lun 3 set 2007, 21:20
Nome Cognome: Mario Vanoni
Slackware: 12.2
Kernel: 3.0.4 statico
Desktop: fluxbox/seamonkey
Località: Cuasso al Monte (VA)

Re: policykit

Messaggio da Mario Vanoni »

Anche i vari *BSD cominciano, pure opensolaris ...
La semplicita` di UNIX scompare,
ultima ratio sara` un LFS creato a mano, pezzo per pezzo!

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Re: policykit

Messaggio da masalapianta »

Savius ha scritto:Grazie mille per il tuo post Masalapianta!!! :D
Ero tra quelli che non si capacitava del perché Pat avesse così tanta ostilità nei confronti delle PolicyKit! :D Però c'è una cosa che non condivido e che riguarda le tue considerazioni personali. Il compito di noi Informatici è quello di "astrarre" da problemi complessi soluzioni semplici in modo da riuscire a risolverli e comprenderli al meglio. Secondo il tuo modo di vedere le cose allora non dovremmo neanche usare dei linguaggi di alto livello ma programmare direttamente in assembler (giusto per dirne una) perché linguaggi come il C, Java eccetera ti "semplificano" la vita e fanno ciò che, in maniera estremamente più complessa, fanno anche linguaggi di basso livello.
forse non mi son ben spiegato, il mio discorso cui fai riferimento e' relativo ai nuovi utenti e a quelli che in generale non hanno un'idea ben chiara di come funzioni un OS *nix come gnu/linux (non a caso parlo di cose fortemente _diseducative_).
Se hai un'idea ben chiara di cosa ci sia sotto il layer d'astrazione allora non e' un problema utilizzarlo (perche' poi sai comunque dove mettere le mani in aso di problemi); viceversa se per te quello che c'e' sotto e' una black-box, allora
quando le cose non funzionano son dolori; per questo non consiglio mai ai nuovi utenti distribuzioni complesse come ad esempio ubuntu, ma gli dico di cominciare con distro semplici come slackware e solo dopo essersi fatti le ossa, se lo desiderano, passare a cose piu' complesse.
Lo stesso discorso si puo' riportare ai linguaggi, e' ovvio che per essere un buon programmatore, anche se usi linguaggi di alto livello devi avere un'idea molto chiara di come funzionino le cose a basso livello (e infatti per cominciare a programmare io consiglio sempre di studiarsi l'equivalente di un esame di architettura degli elaboratori e poi farsi le ossa sul C e mai di cominciare con linguaggi a piu' alto livello), altrimenti produrrai una vagonata di bestialita' a livello di ottimizzazione e sicurezza (il linguaggio di alto livello ti protegge su alcune cose ma non puo' indicarti l'algoritmo piu' idoneo per ciascun caso).
Io sono uno di quelli che vuole le cose semplici: vorrei ad esempio che esistesse qualcosa di meno complesso per creare pacchetti per Slackware
attenzione, confondi semplicita' con facilita' d'uso e complessita' con difficolta' d'uso; in generale, in informatica, quel che e' semplice e' difficile da usare e quel che e' complesso e' facile da usare (laddove con "difficile da usare" si intende qualcosa con una ripida curva di apprendimento)
Se riscontro un problema ALLORA mi studio il tutto e vedo come risolverlo
scusa ma non mi sembra molto furbo, cosi' fai il doppio della fatica come ritengo di aver chiarito nel primo post

P.S. assembly non assembler (l'assembler e' il linker/compilatore, il linguaggio si chiama assembly)

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Re: policykit

Messaggio da masalapianta »

Mario Vanoni ha scritto:Anche i vari *BSD cominciano, pure opensolaris ...
La semplicita` di UNIX scompare,
ultima ratio sara` un LFS creato a mano, pezzo per pezzo!
attenzione, policykit non sotituisce alcunche', anche su distro che ne fanno uso nessuno vieta di gestire il sistema con i vecchi metodi; certo che, come ho detto nel primo post, se si utilizzano DE che hanno una forte integrazione con il sistema e con se stessi non ha molto senso non utilizzare policykit (che segue pedissequamente la filosofia del DE che si e' scelto di utilizzare)

Avatar utente
Savius
Linux 3.x
Linux 3.x
Messaggi: 553
Iscritto il: gio 14 ago 2008, 13:45
Slackware: Slackware64 14.0
Kernel: 3.2.29-smp
Desktop: KDE 4.8.5
Località: Napoli

Re: policykit

Messaggio da Savius »

No ma ti sei spiegato bene è solo che non mi trovo col tuo discorso... ^^'' Perché in teoria allora non dovrei usare Linux visto che non lo conosco benissimo. Non so come è strutturato HAL e non saprei mettervi mano nel caso accadesse chissà che problema però lo considero uno strumento utilissimo e lo userei lo stesso. Cioè non so se mi spiego: è impossibile che io conosca tutto ciò che uso ma non per questo evito di usare cose complesse per il timore di non saper poi mettervi mano nel caso non funzionino come dovrebbero. Con Slackware ho imparato più cose in una sola settimana di utilizzo rispetto a mesi di utilizzo di Ubuntu e Mandriva e questo perché Slackware ha pochi strumenti di "automazione" (lasciami passare il termine) rispetto a quelle distro citate. Però, pur essendo tutte cose che si fanno manualmente, non sono complesse e richiedono poco sforzo nell'essere apprese. E' molto più semplice - per intenderci - installare una Slackware piuttosto che creare un pacchetto (per il sottoscritto) ed è questo a cui mi riferisco io. Mi scuso se il post sta uscendo un po' fuori topic ma solo vorrei cercare di esprimere al meglio un concetto... ^^''

Anche la distinzione tra "semplice" e "facile da usare" non la capisco: io sto parlando di semplicità d'uso e non "procedurale". Non sto valutando quel che c'è a monte ma solo quel che mi ritrovo a valle! Sarò io fissato su sta cosa ma proprio ho un rigetto nel dover seguire tutti quei passi solo per crearmi un pacchetto e con questo non sto assolutamente dicendo che sia sbagliato seguirli eh! Tanto di cappello a chi è riuscito a spiegare bene tutto quello, solo sarebbe meraviglioso se un giorno non molto lontano io possa usare un'applicazione che mi permetta di creare un pacchetto da sorgente senza problemi e senza aver bisogno di conoscere le procedure che esegue per crearlo. E' una questione di punti di vista. Non uso altre distro e mi trovo bene con Slackware perché mi ha insegnato e continua ad insegnarmi tanto e fa tutto quello che io decido debba fare senza agire di testa sua installando cose che non mi servono ma non per questo sono tenuto ad imparare tutto di lei!

Grazie per la precisazione su "assemby" e "assembler" sicuro non la dimenticherò più questa distinzione. Il problema non mi si era mai posto visto che è un termine che usavo alle superiori e davo per scontato fosse corretto, grazie! :D

Avatar utente
phobos3576
Staff
Staff
Messaggi: 2980
Iscritto il: dom 17 apr 2005, 0:00
Slackware: 13.1
Kernel: 2.6.37-smp
Desktop: KDE 4.5.3

Re: policykit

Messaggio da phobos3576 »

Per farla breve, sino ad ieri era difficilissimo scrivere virus, trojan e dialer per Linux; in seguito alle proteste degli "sviluppatori", da oggi finalmente è disponibile una apposita API: si chiama PolicyKit!

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Re: policykit

Messaggio da masalapianta »

Savius ha scritto:No ma ti sei spiegato bene è solo che non mi trovo col tuo discorso... ^^'' Perché in teoria allora non dovrei usare Linux visto che non lo conosco benissimo.
vedi che non mi son spiegato bene? il discorso non e' non usare cio' che non si conosce, ma studiare cio' che non si conosce ma si vuole gestire, oltre che usare
Non so come è strutturato HAL e non saprei mettervi mano nel caso accadesse chissà che problema però lo considero uno strumento utilissimo e lo userei lo stesso.
nessuno te lo impedisce, cio' non toglie che con questo approccio si fa il doppio della fatica e alla lunga si perde molto piu' tempo
Cioè non so se mi spiego: è impossibile che io conosca tutto ciò che uso
l'importante e' conoscere cio' che si gestisce
ma non per questo evito di usare cose complesse per il timore di non saper poi mettervi mano nel caso non funzionino come dovrebbero.
ripeto:
nessuno te lo impedisce, cio' non toglie che con questo approccio si fa il doppio della fatica e alla lunga si perde molto piu' tempo
Con Slackware ho imparato più cose in una sola settimana di utilizzo rispetto a mesi di utilizzo di Ubuntu e Mandriva e questo perché Slackware ha pochi strumenti di "automazione" (lasciami passare il termine) rispetto a quelle distro citate. Però, pur essendo tutte cose che si fanno manualmente, non sono complesse e richiedono poco sforzo nell'essere apprese. E' molto più semplice - per intenderci - installare una Slackware piuttosto che creare un pacchetto
ma e' ovvio che, anche mantenendo costante il livello d'strazione, alcune cose risulteranno piu' complesse ed altre piu' semplici, ma questo che c'entra con il discorso di cui si parlava?
Anche la distinzione tra "semplice" e "facile da usare" non la capisco
non c'e' nulla da capire tu parli di semplicita' intendendo facilita' d'uso, mentre in informatica quasi sempre cio' che e' semplice e' difficile da usare e cio' che e' complesso e' facile da usare
: io sto parlando di semplicità d'uso e non "procedurale".
ripeto: semplice e' diverso da semplice da usare; nel primo caso la mancanza di complessita' e' propria dell'oggetto cui si applica l'aggettivo mentre nel secondo caso e' propria dell'utilizzo di tale oggetto
Non sto valutando quel che c'è a monte ma solo quel che mi ritrovo a valle! Sarò io fissato su sta cosa ma proprio ho un rigetto nel dover seguire tutti quei passi solo per crearmi un pacchetto e con questo non sto assolutamente dicendo che sia sbagliato seguirli eh!
io temo di parlare arabo o tu hai letto un altro post che non e' il mio: il mio discorso e' riferito a chi non sa come funzionano le cose sotto al layer d'astrazione, non ha senso applicarlo anche a chi gia sa come si crea un pacchetto "a basso livello", anzi non c'e' alcun problema se quest'ultimo tipo di utente decide di utilizzare tool che automatizzino la procedura di creazione del pacchetto
Tanto di cappello a chi è riuscito a spiegare bene tutto quello, solo sarebbe meraviglioso se un giorno non molto lontano io possa usare un'applicazione che mi permetta di creare un pacchetto da sorgente senza problemi e senza aver bisogno di conoscere le procedure che esegue per crearlo.
non e' molto complesso fare un'applicazione simile (debian, come redhat o altre ce l'hanno), e nessuno ti vieterebbe di usarla, cio' non toglie che se lo fai senza conoscere quello che l'applicazione fa, nel caso di problemi (che ci sono sempre) ti ritrovi a fare il doppio della fatica e a perdere il doppio del tempo
E' una questione di punti di vista.
no, attenzione, non e' una questione soggettiva: e' oggettivo che alla lunga si perda molto piu' tempo e si faccia molta piu' fatica con un approccio che privilegi l'utilizzo di layer d'astrazione allo scopo di non dover apprendere cosa ci sia sotto al layer (come ho detto, utilizzarli sapendo cosa accade sotto non e' un problema); la dimostrazione e' banale:
attuando un approccio che prevede un apprendimento di come le funzionino le cose prima di utilizzare layer d'astrazione che nascondano tali cose, porta a perdere una volta sola mediamente un tempo x per l'apprendimento di ciascuna cosa, dopodiche si perde mediamente un tempo y per la risoluzione dei problemi che si presentano
quindi avremo che il tempo totale perso in un tot tempo dall'inizio sara' mx+ny (laddove n e' il numero di problemi che si incontrano e m il numero di cose studiate);
viceversa con un approccio che privilegi l'utilizzo di layer d'astrazione, allo scopo di non dover apprendere cosa ci sia sotto al layer, non si perdera' alcun tempo nell'apprendimento di come funzionano le cose sotto al layer, quindi si avra' che il tempo totale perso in un tot tempo dall'inizio e': ny+nk (laddove k e' il tempo medio aggiuntivo da spendere nella risoluzione di ciascun problema a causa della non conoscenza di come funzionano le cose)
E' quindi ovvio che a meno di x infinito, avremo che in un tempo finito con il primo approccio si arriva a perdere meno tempo (e quindi fare meno fatica)

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Re: policykit

Messaggio da masalapianta »

phobos3576 ha scritto:Per farla breve, sino ad ieri era difficilissimo scrivere virus, trojan e dialer per Linux; in seguito alle proteste degli "sviluppatori", da oggi finalmente è disponibile una apposita API: si chiama PolicyKit!
grazie dell'assist, mi ero completamente scordato di chiarire questo aspetto:
utilizzando regole di autorizzazione basate su uid o su sessione-desktop (con quelle basate su pid e start time non si hanno questi problemi) si creano delle potenziali voragini di sicurezza se non si ha un'idea piu' che cristallina di cosa si stia facendo in fase di configurazione del framework: questo perche' una regola valida per una data applicazione poi viene estesa a qualunque applicazione eseguita da quell'utente, dando permessi che dovrebbe avere solo root a qualunque codice malevolo eseguito in qualunque modo dall'utente

Avatar utente
Savius
Linux 3.x
Linux 3.x
Messaggi: 553
Iscritto il: gio 14 ago 2008, 13:45
Slackware: Slackware64 14.0
Kernel: 3.2.29-smp
Desktop: KDE 4.8.5
Località: Napoli

Re: policykit

Messaggio da Savius »

Fidati è questione di punti di vista... :p Ti faccio io un esempio: mettiamo caso che in Slackware vi sia un'applicativo che è sempre funzionato alla perfezione in tutte le versioni della distro e che, all'improvviso, dia qualche problema. Ora, secondo te cos'è più dispendioso studiarmi tutta la Slackware in modo da saper poi riconoscere e correggere un eventuale errore di un determinato applicativo o preoccuparmi del singolo problema quando verrà riscontrato? Sicuramente nel secondo caso impiegherò molto più tempo a risolverlo rispetto a se avessi conosciuto tutta la Slackware ma di sicuro non dovrò studiarmi tutta la distro per risolvere un singolo problema ma mi basterà vedere solo le cose cui esso va ad intaccare...

Il tuo approccio è giustissimo e si dovrebbe applicare a tutte le cose ma, nella realtà, è quasi impossibile da applicare. Se ad esempio funzionasse tutto come dici tu allora nel mondo si eviterebbero tanti incidenti e ci si riuscisse a porvi rimedio prontamente ed efficientemente ma, purtroppo, ci si accorge dei problemi solo quando questi capitano e quasi mai ci si prepara prima. Capisci cosa voglio dire? Non dico che sbagli nel vederla in questo modo dico solo che non lo condivido. Io ho studiato Informatica alle superiori e sto per laurearmi nello stesso campo all'Università ma mi sento sempre un n00b e non perché effettivamente lo sia (magari lo sono però :p), ma perché non si finisce mai di imparare e se le cose restassero sempre complesse come sono (e mi riferisco alla complessità d'uso) non vi sarebbe mai un'evoluzione nel campo dell'IT.

Ho capito il discorso tuo che si riferisce non all'utilizzatore di un determinato strumento ma al "gestore" di quest'ultimo ma, sebbene i termini possano essere diversi, io continuo a notare una certa similitudine perché se uno strumento funziona io mi limito ad usarlo e non a gestirlo, me lo gestisco se non fa quel che dico io e in quel caso ho bisogno di conoscerlo. (Questa è davvero difficile da capire perché noto una certa ambiguità anch'io ma ti assicuro che ha un senso... ^^'')

Avatar utente
conraid
Staff
Staff
Messaggi: 13630
Iscritto il: gio 14 lug 2005, 0:00
Nome Cognome: Corrado Franco
Slackware: current64
Desktop: kde
Località: Livorno
Contatta:

Re: policykit

Messaggio da conraid »

thanks masala :-)

pino
Linux 3.x
Linux 3.x
Messaggi: 591
Iscritto il: ven 18 gen 2008, 15:34
Nome Cognome: Pino
Slackware: 14
Desktop: kde
Località: Torino

Re: policykit

Messaggio da pino »

Finalmente ho,un po, capito cos'è sto policykit. Grazie a masalapianta
Comunque è anni che mi cambio le pastiglie dei freni da solo ma porto la macchina dal meccanico per cambiare la cinghia di distribuzione.
Ciao Pino

Avatar utente
NetNightmare
Linux 1.x
Linux 1.x
Messaggi: 175
Iscritto il: lun 18 ago 2008, 11:00
Nome Cognome: Giuseppe De Nicolo'
Slackware: 13.37 x86_64
Kernel: 2.6.37.6-smp
Desktop: Fluxbox
Località: Rome

Re: policykit

Messaggio da NetNightmare »

Questo e' un tipo di post che mi piacerebbe vedere molto spesso, ti ringrazio per aver impiegato un po del tuo tempo per scriverlo, molto interessante...e riguardo le considerazioni personali mi trovi altrettanto daccordo ... :thumbright: :thumbright: :thumbright: :thumbright:
Ultima modifica di NetNightmare il gio 4 mar 2010, 19:00, modificato 1 volta in totale.

sir_alex
Linux 3.x
Linux 3.x
Messaggi: 735
Iscritto il: lun 21 mar 2005, 0:00
Kernel: 2.6.35-22
Desktop: KDE4
Distribuzione: Ubuntu
Località: Milano - Corbola (RO)
Contatta:

Re: policykit

Messaggio da sir_alex »

Grazie per l'ottima spiegazione, ora le idee sono decisamente chiare.
Vorrei però fare una considerazione, sulla preoccupazione espressa in questo thread e che non mi sento di condividere appieno: per quanto io possa essere d'accordo con i layer di astrazione (anche se forse non completamente), qui si parla di utenti anche amministratori che, la stragrande maggioranza delle volte, avranno bisogno dei permessi di root per eseguire operazioni come l'installazione di software piuttosto che la configurazione della rete, quindi operazioni in linea di massima abbastanza banali.
E' chiaro che entrambi questi esempi possono portare ad incasinare il sistema, tuttavia non vedo cosa l'utente dovrebbe conoscere per poter usare senza problema il layer di astrazione: nessuna di queste operazioni (dall'aggiornamento del sistema al collegarsi alla rete wifi di casa) comporta la reale necessità di sapere come funziona ad es. lo stack TCP/IP o ifconfig+iwconfig+wpa_supplicant+whatever, secondo me la percentuale di utenti che potrebbero "incasinare" le cose avendo privilegi che permettano loro di compiere operazioni potenzialmente pericolose (e mi sembra sia questa una delle preoccupazioni) penso sia molto minore del 99%...

Rispondi