sabato 30 marzo 2013

Usare lo stesso UID fra account differenti

Alcuni sistemi Unix, come ad esempio FreeBSD, forniscono effettivamente due utenti root: il classico root e il suo rovesciato toor. Per verificare la presenza di questi due utenti e' sufficiente usare il seguente comando:

% grep "^[rt]oo[rt]:" /etc/passwd
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:

L'idea e' semplice: root e' l'utente impostato all'atto dell'installazione e non dovrebbe mai essere personalizzato (ad esempio modificandone la shell), al fine di garantire che in situazioni estreme (es. single user mode) l'account funzioni come ci si aspetta (o meglio come si aspetta il sistema). Il suo rovescio, toor, e' invece un account che puo' essere personalizzato ad esempio impostando una shell differente (presa da /usr e non disponibile in single user mode).
Si noti che i due account condividono lo stesso UID (0) e quindi sono di fatto lo stesso account, solo con entry differenti nei vari database.

Oggi giorno non esiste piu' la reale necessita' di usare una simile tecnica, grazie a strumenti come sudo che consentono una personalizzazione di account utente normali estrema. Alcune distribuzioni Linux non forniscono nemmeno un account root disponibile, forzando l'utente a configurare sudo.
Ancora oggi pero' qualcuno e' tentato da usare questa tecnica dei doppi account per separare privilegi, personalizzazioni, ecc. La mia risposta breve e': NON FATELO!
In generale potrebbero esserci applicazioni che, stupidamente, ritengono che un UID sia unico. E queste si riveleranno sicuramente come una falla di sicurezza. Dopotutto, la generazione di /etc/passwd da /etc/master.passwd non e' per via di alcune applicazioni "stupide" che richiedono accesso al database degli utenti?
In secondo luogo, il sistema potrebbe confondersi, non facendovi vedere chi ha creato quali file:

# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
root@fb91:/root # touch test.txt
root@fb91:/root # ls -l test.txt
-rw-r--r-- 1 root wheel 0 test.txt

# su - toor
# touch test2.txt
# ls -l test2.txt
-rw-r--r-- 1 root wheel 0 Mar test2.txt

L'ownership dei file viene presa assumendo il primo record che si trova nel database (forse ls e' da considerarsi una applicazione stupida? In realta' non saprebbe come fare a discriminare gli utenti). Quindi condividere utenti/privilegi con questo metodo vi fa perdere, gratis e con effetto immediato, la tracciabilita' di quale utente ha toccato quali file.

La strada corretta per gestire in sicurezza i privilegi e' usare sudo.

giovedì 28 marzo 2013

Document Freedom Day (e siamo al 2013!)

Anche se ormai sono regredito fino al puro file di testo (grazie ad OrgMode!), non posso esimermi dal festeggiare il Document Freedom Day 2013!

Buon documento libero a tutti!


martedì 26 marzo 2013

Viaggiare in treno è una truffa (legalizzata)!

Disclaimer: quanto qui riportato è una mia personale opinione dovuta all'esperienza maturata in anni di viaggi in treno. Nessuna compagnia di trasporti viene citata esplicitamente.

Negli ultimi anni sono diventato un affezionato del viaggiare in treno.
Fondamentalmente e' un mezzo di trasporto comodo, sicuro, veloce, puntuale e che permette un viaggio rilassato e sereno, impiegando il tempo del tragitto in altre attivita' differenti dalla guida.
Tutto questo sarebbe certamente vero se non stessimo parlando del sistema ferroviario nazionale (e a dire il vero anche di quello regionale e provinciale).
Che i treni siano puntuali in Italia e' una pura utopia: ho assistito a scene degne del film "Ritorno al Futuro" con annunci di treni in ritardo che poi sarebbero partiti in anticipo, senza considerare che gli orari non erano compatibili. Spesso mi sono trovato ad arrivare a casa ore dopo per via di un ritardo che, con effetto valanga, ha causato la perdita di coincidenze. Una volta sono stato costretto a cambiare itinerario andando perfino nella direzione opposta pur di riuscire a prendere un treno che mi portasse dove volevo con solo 4 ore di ritardo!
Insomma, inconvenienti che capitano quando si viaggia.
Certo sarebbe bello poter impiegare il tempo del viaggio facendo altro, magari leggendo o schiacciando un pisolino. Almeno si noterebbe meno il ritardo. Ma sui nostri treni, sporchi e puzzolenti, spesso sovraccarichi di gente costretta a viaggiare in piedi, anche questo diventa utopia.
Eppure continuo a prendere il treno, anche per necessita'.

Pero' ultimamente mi sono scontrato con le ultime tariffe, che mi hanno indotto a pensare. Non importa quale fornitore di servizio si scelga, il ragionamento e' analogo e le tariffe sono molto simili.
Si prenda un biglietto "economy", che tipicamente ha lo stesso costo del tragitto fatto in automobile. Questo biglietto non e' assolutamente rimborsabile. Non importa quanto tempo prima si voglia dare disdetta, non importa se si sia impossibilitati a partire, il biglietto non e' rimborsabile (a meno che i carabinieri vi abbiano trattenuto, nel qual caso il problema non e' solo il biglietto!). Cosa si deve fare allora per avere un biglietto rimborsabile? Si deve prendere la tariffa "base". Qual'e' la differenza fra i due? Ebbene il biglietto "economy" solitamente costa un 45-50% in piu' di quello "economy" e nel caso di rinuncia al viaggio si ha un rimborso complessivo dell'80%.
Facciamo un esempio pratico: un biglietto economy da 50 euro, che in tariffa base supponiamo essere 100 euro. Se si rinuncia al biglietto base si sono buttati via 20 euro, se si rinuncia all'economy se ne buttano via 50. La differenza e' quindi che in questo ultimo caso si sono buttati via 30 euro in piu', ma se ne sono pagati 50 in meno se si effettua il viaggio. E questo dovrebbe essere il "rischio" che si assume il fornitore. Rischio che mi sembra, francamente, molto alto. Anche perche' ci sono biglietti che possono costare molto, e quindi troverei sicuramente piu' giusto dare all'utenza la possibilita' di rinunciare al viaggio (anche "economy") entro una certa data e/o per una certa fascia di importo. O almeno che si dia un credito al viaggiatore da usare su altri biglietti.
Si consideri anche che la rinuncia di un biglietto, non cedibile, significa avere treni che viaggiano scarichi e magari altri treni piu' carichi. Avere un meccasnismo di rinuncia e cessione potrebbe facilitare il raggiungimento di una soglia di occupazione maggiore. Eh si, perche' se io prenoto 10 biglietti e vi rinuncio, ci saranno altri 10 viaggiatori che non potranno viaggiare su quel treno, ma di fatto 10 posti saranno liberi.
E si consideri, come ultimo fattore, che sempre piu' biglietti vengono comprati on-line, ove il rischio di sbagliare data e orario e' abbastanza alto grazie anche a sistemi web spesso incomprensibili. Fornire quindi la possibilita' di annullare o confermare una prenotazione risulta segno di civilta' ed educazione.

Riflessione finale: nemmeno gli hotel o i ristoranti sono cosi' rigidi con le prenotazioni, anche quando si specifica la propria carta di credito. Provare per credere!

E giusto per contestualizzare il titolo del post, che si riferisce al Bel Paese: le ferrovie Die Bahn recitano chiaramente sul loro sito, per la tariffa base quanto segue
Prezzo per tutti i viaggiatori. Completa flessibilità (biglietto non vincolato al treno). Cambio/rimborso gratuito, a partire dal 1° giorno i validità con penale di 15 EUR. 

venerdì 1 marzo 2013

My story about using Perl

I first met Perl on a book related to Red Hat Linux 6: at the end of the book there was a few chapters about programming and deploying on Linux and one of those chapter was dedicated to Perl.
However at that time I was not interested in Perl at all and I thought Java was the only true language.
Oh poor my!
The fact is that I was a young university student and I was truly believing what teachers were telling me, and teachers were truly believing what Sun Microsystem was telling them...
A couple of years later I start being interested in Perl. The truth is I was interested in this cool scripting thing that allowed me to build up very complex programs using little pieces and combining them and, oh mama look, you don't have to compile and deal with pointers and type declarations and all other stuff that real big programs require you to focus on. And by the way, the final result is the same.
Having read something about Perl in a Linux book, as already stated, I thought that Perl was the right language for me to learn to jump out "boring" Shell scripting and do even more. Therefore I asked to my
girlfriend (err..now ex-girlfriend) to buy me the camel book for  Christmas, and she did, and so I passed my holidays reading about Perl. Ok, the Italian version of the camel book was quite horrible, due to wrong translations and formatting, and therefore I had to read it more than once to get even the simpler concepts.
In the beginning I was rejecting Perl. What the hell, why should I write something like:

print "Hello World!" if( ! $rude );

while in all the other structured C-based programming languages I know I have to write:

if( ! $rude )
  print "Hello World!";

Well, I have to admit, Perl has a quite weird syntax, and can be confusing in the beginning (this is the reason why I appreciate Python, even if I don't know it very well). However, as the camel book authors' say, you don't have to exploit every piece of the syntax and can do a baby-like programming. And so I started doing a baby-like programming. But excluding some really tiny personal projects, like file formatting and text mangling, I was not developing very much in Perl.

A few years later I was in charge of administering one University laboratory made by a few Sun Workstations.
One of my tasks was to generate a lots of accounts for all the students  attending the courses. My tutor was a Shell addicted, and therefore was using some poor-quality Shell scripts to do the job. I was a junior administrator and I was not aware of programs like pw and similar (neither was my tutor!) and therefore I wrote a quite long Perl script that did all the job including creating directories, shares, profile files
and passwords. I think this was my first real Perl program at all!

A few months later I was consulting for a factory that was using an Hylafax server to send faxes, and I was in charge of producing a report about outgoing faxes and I used Perl again to study the server logs. In a few hours I did the job!

From the above I was realizing that Perl allowed me to solve complex problems, or apparently complex problems, with a few lines of code and in a more elegant way than Shell did. And so I start using Perl for a lot of
small glue applications.

One day I even used Perl for a kind of evil aim, or better to contrast an evil task. My boss was angry with me and therefore gave me a stupid task to make me waste my time: substitute in almost one hundred source files a few strings, recompile them and deploy. Since I was forced to do it connected to a remote machine without any kind of file sharing (and therefore to use locally a powerful editor) and an X server, my boss thought this would have kept me busy for half a day. I spent half an hour writing a Perl script that did all the job for me and I spent the rest of time on the Web! Well, I have to admit, that if I knew Emacs as I know today I would have rather used it, but that was the power that Perl gave me: I was able to code what I wanted to do in a simpler manner even if I had not or did not know about the right tool to use!

At the university I was also in charge of teaching programming languages, that at that time were C and Java. I asked the professors several time to let me do even one single lesson about Perl, without success (again, I guess it was the Sun Microsistem evangelism...). And I found that Perl was rejected not only as a language to teach, but also
as a language to use: when I told my colleagues I was using Perl in my consultancy they were looking at me as I was a poor developer. I felt like they were judging me as I was not able to write an OOP program and compile it, linking and running it, and therefore I needed something simpler to write and launch. And I think this is still true here in Italy, since Perl (and to some extent even Python) is seen as something that you use only if you are unable to design a system full of objects and messages.

By the way, I was happy with Perl and continued to use it as my glue private tool.

A few years later I was in charge of developing my first Web application, and of course the tool I used was Perl. At that time CGI seemed to me the right tool to use, but of course it was not the right choice since more powerful framework like Catalyst were recommended. Anyway, the application was developed quite fastly and did what was required. Unluckily, the client decided later to rewrite the same application using Java and a client-server approach. Despite the latter, the size of the code (not its quality) was at least four times of the Perl one!

Today I would like my day to day job involves Perl, but as already stated I believe this great language is not well understood here in Italy, and therefore I have to use it again as my private glue tool.