select * from depesz;

in most applications you have some variant of this table:

CREATE TABLE users (
id serial PRIMARY KEY,
username TEXT NOT NULL,
passwd TEXT
);

and, usually, the passwd stores user password in clear text way.

this is usually not a problem, but in case you’d like to add password encryption in database, there are some ways to do it - and i’ll show you which way i like most.

- MORE -

ever seen one of those? i mean the “fatal: ident authentication failed”?

or, ever seen anyone having this problem when connecting to postgresql?

how often is this problem related to debian/post-debian linux distributions? 99%? 100%?

on #postgresql on irc.freenode.net it is the most common problem. my own irc logs show that “ident” showed over 300 times over last 41 days. now, that’s something. and how come we have this problem? what can be done with it? read on.

- MORE -

so there you go, you have some “categories” and some objects. for simplicity let’s assume one object can be in only one category.

if this is too theoretical for you - let’s assume these are “mails in folders”, “photos in galleries”, “posts in categories” or “auctions in categories on ebay”.

everything clear? now, let’s assume you want to know how many “objects” are in given “category”.

most basic way to do it is:

select count(*) from objects where category = some_category;

but this method is far from optimal. now, we’ll learn how to do it better.

one warning for those of you who read the rss feed - if you say “yeah, i know the code, it’s simple” - ask yourself - is your code deadlock-proof?

- MORE -

now, some time ago i wrote about how to “hack” system with postgresql. today i’ll write more about how to make pg database as safe as possible.

i’ll go through several steps, tell you what’s possible, what’s easy, and what is not so easy

so, let’s start the tutorial.
- MORE -

< french translation is now available >

very recently i got a task which involved finding out what happened (what sql queries were called) on remote machine.

the problem was that i didn’t have any kind of shell access to server - i could connect only to postgresql. the good side was that i had a superuser-level access.

so the task was quite simple - how to find and read a file from psql. on remote machine. with no access to ssh, ftp, nor anything like this.

this is when i got idea that i’ll write more about it. some might say that you shouldn’t write this kind of information. my view is that i’m not disclosing any secrets - i will be using only basic (remote) psql with superuser access. all things that i will describe in here are in documentation - you just have to know where to look for them.

- MORE -

how many times did you (or somebody in your environment) did something like this? update (or delete) without proper “where”?

it happened at least couple of times to me.

of course - using transactions solved the problem. but - on the other hand - if i can’t trust myself to add proper where, how can i trust myself to add “begin”?

so, is there no hope?

are we doomed to always repeat the same mistake, and spend uncountable hours on recovering from damaged tables?

fortunatelly there is a help.
- MORE -

google przeprowadził na sporą skalę testy awaryjności dysków - stestowano ogółem 100,000 dysków o pojemnościach od 80 do 400 giga. dyski te były wcześniej używane przez google’a, więc (zgodnie z polityką google) nie były to jakieś cuda, tylko standardowe dyski dostępne w sklepach.

rezaultaty? przede wszystkim - brak powiązania między częstotliwością używania dysku a awaryjnością. to samo tyczy temperatury - niby wysoka temperatura szkodzi, ale w rzeczywistości tak nie jest.

jedynynie bardzo młode i bardzo stare dyski zachowują się zgodnie z popularnymi wierzeniami. dyski które nie padły od razu - trzymają się dobrze długo.

warto przeczytać cały tekst - daje kilka ciekawych informacji nt. symptomów i prawdopodobieństwa.

wykryto właśnie poważny błąd w postgresie w obsłudze funkcji typu “security definer”. błąd tyczy się wszystkich wersji postgresa od kiedy to wprowadzono - czyli od 7.3.

błąd pozwala na wykonanie dowolnego kodu z podwyższonymi uprawnieniami i daje się wykorzystać podobno w przypadku większości funkcji zdefiniowany jako security definer (ale nie wszystkich).

na szybko kod można poprawić i zabezpieczyć ustawiając na sztywno w funkcji search_path’a.

prace nad poprawieniem tego trwają.

od dawna wiadomo, że największym zagrożeniem dla firmowych systemów informatycznych nie są hackerzy czy konkurencja, ale pracownicy. ci głupi i ci źli.

ostatnie badania tyczyły się tego którzy pracownicy sabotują firmowe systemy it. odpowiedź nie jest przesadnie szokująca - najczęściej są to informatycy (86%). dodatkowo - 90% osób robiących coś takiego ma wyższe od standardowych uprawnienia w sieci!

po czym poznać potencjalnego terrorystę firmowego? raport sugeruje:

• gderliwi/narzekający
• paranoiczni
• spóźniający się często
• kłócący się z kolegami
• ogólnie kiepsko pracujący

hmm … mam paranoję. często narzekam. co do spóźniania - ciężko mi to ocenić - to samo z ogólnymi wynikami.

no ale kłócić się nigdy nie kłócę. jestem miły, uczynny i pomocny. czyli to nie o mnie.

na listę announce’ów poszedł mail informujący by *nie* instalować ostatnio wypuszczonych wersji postgresa (8.2.2 i 8.1.7). przyczyna: jest błąd w obsłudze typów tekstowych.

werjsa 8.0 i wcześniejsze podobno nie mają problemów, ale jeszcze są testowane.

nowe wersje nie zostały jeszcze oficjalnie obwieszczone, ale na ftp’ie już są.

muszę przyznać, że za mojej pamięci to pierwsza taka sytuacja.