sudo: root o utente?

Ormai quasi tutti si sono abituati all'uso di sudo, un software che consente di fornire credenziali elevate (di amministratore) ad utenti normali. L'idea è semplice: l'amministratore di sistema fornisce una lista di utenti non amministratori che possono richiedere privilegi maggiori (specificando anche cosa possono fare). Quando uno di questi utenti deve eseguire un programma con privilegi maggiori invoca sudo che gli consente di innalzare i propri permessi.

Se ben usato sudo aumenta anche la protezione del sistema: è possibile con sudo utilizzare un account root senza nemmeno averlo abilitato, e quindi lasciando un account noto (e quindi attaccato) inaccessibile.

Molti sistemi Linux in default installano sudo abilitando per l'utente che ha effettuato la prima installazione. Un caso classico sono gli *buntu in versione sia server che desktop. L'utente quindi con una sola password puo' amministratore il computer.

PCBSD fa una scelta di default differente: abilita sudo per l'utente che effettua l'installazione ma richiede che la password fornita non sia quella dell'utente ma quella di root stesso. 

Qual'è la motivazione di questa scelta, a prima vista inutile? Se durante l'installazione l'utente principale viene abilitato a sudo allora questo avrà la possibilità di accedere direttamente come amministratore, cosa che a volte non è fattibile. Usando invece la password di root solo gli utenti che conoscono tale password saranno abili e abilitati a eseguire comandi privilegiati. Certo, potrebbero farlo come root stesso, ma il sistema puo' continuare a tenere l'account di root disabilitato permettendo un innalzamento dei privilegi dell'utente normale.

Difficile dire quale scelta sia la migliore, probabilmente quella di PCBSD, anche se richiede qualche accorgimento in piu'. In entrambi i casi il comportamento puo' essere modificato dall'amministratore in qualunque momento agendo sul file /etc/sudoer che contiene delle righe simili a:

## Uncomment to allow any user to run sudo if they know the password
## of the user they are running the command as (root by default).
Defaults targetpw  # Ask for the password of the target user

E come riporta la pagina man:

targetpw        If set, sudo will prompt for the password of the user specified
                       by the -u option (defaults to root) instead of the password of
                       the invoking user.  Note that this precludes the use of a uid not
                       listed in the passwd database as an argument to the -u option.
                       This flag is off by default.

Traduzioni Italiane di PCBSD

Avendo avuto un po' di tempo, che ormai è sempre piu' una rarità, ho completato la traduzione di alcuni file di PCBSD in italiano. In particolare desktopschema.po  SysInstaller.po  SystemUpdaterTray.po sono ora completamenti localizzati. Penso possa ritenersi il mio personale regalo di Natale (al quale hanno contribuito altri prima di me) per questo sistema operativo e la sua community. Purtroppo non sono stato in grado di caricare i file sul server ufficiale, perchè sembra che al momento ci sia qualche problemino....

FreeBSD, gmirror e GPT

Con l'imminente uscita di FreeBSD 9 alcuni utenti hanno lamentato problemi nell'utilizzo di gmirror, il tool userland di GEOM che consente il mirroring dei provider (dischi). Il problema e la confusione nasce dal fatto che FreeBSD 9 utilizza GPT come sistema di partizionamento di default per la versione 9, mentre usava il classico e antico MBR per le versioni precedenti. Qual'è quindi la differenza? Nello schema MBR la tabella delle partizioni viene salvata all'inizio del disco, nei primi 512 bytes. Per non sovrascrivere la tabella delle partizioni, GEOM salva le proprie informazioni (label) alla fine del disco. 

GPT, al contrario di MBR, salva anch'esso le proprie informazioni (tabella delle partizioni) alla fine del disco, e quindi puo' nascere conflitto fra GPT e GEOM. Conflitto che porta a confusione, a tal punto che anche Mr. Lucas, nel suo blog, scrive la soluzione al problema. Soluzione che è molto semplice, grazie all'eleganza di GEOM: basta infatti ricordarsi che un provider non è solo un disco fisico, ma anche una singola partizione, e il gioco è fatto! Si tratta quindi di mettere in mirroring non gli hard disk, ma le singole partizioni (cosa peraltro sensata e che ricorda il md di Linux)! Si avrà quindi un disco (o meglio almeno due!) con una GPT alla fine e tante partizioni, ciascuna con una label GEOM alla fine.

App Store: novità o trovata commerciale?

Sembra molto popolare oggi parlare di App Store. L'idea è semplice ed elegante: l'utente che vuole acquistare/ottenere una nuova applicazione per il suo device (computer, palmare, telefonino, ...) si collega ad un repository centralizzato (l'app store appunto), cerca la applicazione che faccia quello che interessa all'utente, accetta il contratto ed eventualmente paga un obolo, scarica l'applicazione che "automaticamente" si installa e il gioco è fatto. 

La gara alla creazione di nuovi app store è iniziata e tutti i vendor non si tirano indietro: c'è lo store per Apple, Android, Microsoft e la lista puo' continuare.

Eppure a me sembra, come riporto in questo thread, che questo concetto non sia nulla di nuovo. Basta infatti rileggere quanto scritto sopra per notare che si ha:

• un repository centralizzato
• un meccanismo di ricerca di una applicazione
• un meccanismo di agreement
• un meccanismo di download
• un meccanismo di installazione

Cosa differenzia quindi un app store da un repository di software? Tecnicamente solo il nome. Si pensi ai repository Debian/Ubuntu, o ai ports di BSD. Cambiano gli strumenti, ma non il risultato. 

Riusciremo mai ad avere un app store globale? No. Dopotutto ancora non c'è accordo su un formato binario che possa andare bene per diversi sistemi, e perfino all'interno dello stesso sistema ci sono proposte differenti per gli stessi sistemi binari (ad esempio IPS vs OpenCSW). 

Pero' gli app store sono piu' pericolosi rispetto ai repository software. L'app store è molto legato alla tecnologia utilizzata (ad esempio Android rispetto ad Apple), molto piu' che un repository software che potrebbe fornire servizi a tecnologie leggermente differenti. Essendo cosi' legato alla tecnologia, l'app store rischia di legare anche l'utente ad essa. Dopotutto i vendor commerciali lo hanno capito: vendere uno smartphone o un pc non serve piu' a nulla. Bisogna vendere dei sistemi integrati. Ecco allora che arrivano le soluzioni all-in-one: telefono, pc, smartphone, televisore tutti dello stesso produttore, con lo stesso software, che si collegano allo stesso app store. La situazione è a tratti tragica: invece che usare la tecnologia per implementare standard interoperabili i vendor si stanno nuovamente chiudendo a riccio per imporre il proprio monopolio (chi si ricorda la guerra dei browser?). 

Non è comunque giusto fare di tutta l'erba un fascio: ci sono anche app store dalle buone intenzioni, che si propongono solo come un layer di semplificazione per l'utente. Un esempio è App Cafe' di PCBSD, che altro non è che un downloader/installer di file PBI.

Qt 4.8

E' ufficiale: le Qt 4.8 sono ora disponibili per il download!

Fra le varie migliorie dovute all'evoluzione della libreria vi è anche un pesante refactoring del supporto al file system al fine di migliorare le già ottime prestazioni in I/O. E ovviamente LightHouse ha fatto in avanti al fine di supportare differenti windowing systems e porre le basi per Qt 5.

CodeSearch

Un interessante post di Miguel De Icaza illustra una considerazione economico-commerciale che ha portato Google a fare una scelta molto discutibile:

It is a shame that Google is turning their back on their officially stated mission "To organize the world‘s information and make it universally accessible and useful". It is a shame that this noble goal is not as important as competing with Apple, Facebook, Microsoft, Twitter and Yelp.

L'affermazione nasce dal fatto che Google chiuderà il validissimo e utilissimo (almeno per i programmatori) servizio CodeSearch, che consentiva una ricerca molto dettagliato all'interno del codice disponibile on-line.

Come curiosita': la ricerca di Datum in CodeSearch restituisce PostgreSQL come terzo risultato. Nessun altro motore di ricerca di codice fino ad ora mi ha dato lo stesso risultato.

Eclipse e il renaming dei getter/setter

Una delle feature che ha maggiormente contraddistinto Eclipse rispetto ad altri IDE è stato il refactoring, introdotto con la versione 2. Nel refactoring, una delle caratteristiche che uso maggiormante nel mio lavoro quotidiano è il rename che consente di modificare il nome di una variabile o metodo andando ad aggiustare automaticamente tutte le occorrenze nel progetto.

Dalla versione 3 di Eclipse il rename non viene piu' fatto tramite una dialog, ma tramite digitazione diretta del nuovo nome in overwrite. Questo ha fatto si che mi scordassi, con il tempo, che Eclipse ha anche la possibilità di aggiustare i nomi dei getter e setter di una variabile. Un collega mi ha ricordato che visualizzando la finestra di dialogo di rename all'atto della rinomina è possibile spuntare i checkbox per rinominare anche i metodi di accesso alla proprietà.