Forum Debian Users Gang

@jacekalex:

Zapomniałeś napisac jedno - czy zaprzyjaźniasz się z Postgresem jako programista czy admin.
Bo jeśli programista... nie wiem z jakimi bazami do tej pory pracowałeś, ale jeśli z Oraclem to znajdziesz tam wiele wspólnego. Nie wspomnę tu o samym dialekcie SQL (np. INSERT ... RETURNING ...), możliwości więcej niż jednego pola serial (odpowiednika naszoklasowego autoincrement) czy pisania sobie triggerów w Twoim Ulubionym Języku Programowania (o ile pamiętam Perl?)

Jeśli admin... cóż, musisz przyjąć do wiadomości smętną prawdę: to co wiesz o naszejklasie nijak się ma do Postgresa. Może jakiś tam kawałeczek podobny znajdziesz... ale jedynie podobny, bo z tego podobieństwa za chwilę wyjdą różnice.

Dam Ci przykład:

Naszoklasowa baza danych istnieje sobie radośnie w przestrzeni naszej klasy, można sobie jakieś granty dawać albo zabierać.
Poztgresowa baza danych ma zawsze swojego właściciela - dokładnie jednego.

W naszejklasie możesz się połączyć z nasząklasą i się cieszyć.
W Postgresie musisz się połączyć z konkretną bazą danych, nie ma czegoś takiego jak "połączyłem się z postgresem".

W naszejklasie masz użytkowników 'kuciapa'@'localhost', 'kuciapa'@'127.0.0.1', 'kuciapa'@'192.168.0.1' i tak dalej. W rzeczywistości są to różni użytkownicy z różnymi uprawnieniami.
W Postgresie masz użytkownika kuciapa, a przez pg_hba regulujesz mu dostęp z różnych miejsc świata.

A najważniejsze:

PhpMyAdmin jest wspaniałym programem, przemyślanym, wygodnym, ogólnie pierwszym narzędziem które instalujesz na serwerze.
Konsola mysql wystarcza do odtworzenia bazy z dumpu, założenia z roota nowej bazy ew. (jak się od Ciebioe dzisiaj dowiedziałem) do sprawdzenia stanu połączenia.

PhpPgAdmin to taka zabawka, niespecjalnie używalna, i instalowanie jej na dzień dzisiejszy mija się z celem.
Konsola psql wystarcza do wszystkiego co chcesz zrobić włącznie z nauczeniem Postgresa śpiewać.

Polecam zapoznanie się z :

man createuser
man dropuser
man createdb
man dropdb
man CREATE_DATABASE
man CREATE_USER

No i oczywiście sztandarowe:

man psql

Zwróć uwagę na parametr -e - zobaczysz wtedy jakie dokładnie kwerendy są wykonywane. Przykładowo:

createdb -e -U postgres -O kuciapka kuciapeczka

mało że założy Ci bazę o nazwie "kuciapeczka" z domyślnymi ustawieniami i właścicielem "kuciapka" (zakładam że user "kuciapka" nie ma uprawnień do zakładania baz danych i jako superuser musisz mu to zrobić) - to jeszcze wyświetli wszystkie kwerendy które zostały wykonane, aby takową bazę stworzyć.

To samo dotyczy psql.

Tak przy okazji - dużo można w gógielu znaleźć, czasem można trafić na artykuły podpisane nickiem "depesz" - jeśli taki znajdziesz warto przeczytać, bo to gość który wychował całe pokolenie polskich (i nie tylko) postgresiarzy (i ogólnie bazodanowców).

Przyjemnego postgresienia :)

Ostatnio edytowany przez ethanak (2014-07-20 13:13:18)

jeśli coś działa na 8.x (gdzie x>0) to będzie działać na 9.
jak się bawiłeś uprawnieniami to masz doskonałą okazję nauczyć się jak się odpsuwa zepsute bazy.
zaloguj sie jako postgres i daj granta na wszystko w tej bazie userowi ejabberd, powinno pomóc.
ewentualnie (stara dobra szkoła) zrób dumpa w sql, wywal z dumpa niepotrzebne granty, utwórz nową bazę i zaimportuj - sam wiesz że może być szybciej.

Jacekalex napisał(-a):

Zdecydowanie jako Admin, potrzebuje serwer Voip Freeswitch i XMPP Ejabberd wygonić do Postgresa.
Wcześniej wszystko chodziło przez ODBC z Mysql, ale zjebał się sterownik Myodbc, i powstała wspaniała okazja, żeby lepiej się zaprzyjaźnić z Postgresem. xD.
Niestety, z bliżej mi nieznanych (i trudnych do zlokalizowania) przyczyn zdechł PHPPGAdmin, muszę się certolić z uprawnianiami w PgAdmin3/Webmin/Konsola, i z tym chyba mnie zaraz szlag trafi.

W tej chwili mam taki numer, że co prawda użytkownik ejabberd jest właścicielem bazy ejabberd, ale tylko bazy, tabel już nie.

Kod:

                                      Lista baz danych
   Nazwa    | Właściciel | Kodowanie | Porównanie  |    Ctype    |    Uprawnienia dostępu    
------------+------------+-----------+-------------+-------------+---------------------------
 ejabberd   | ejabberd   | UTF8      | pl_PL.UTF-8 | pl_PL.UTF-8 |

I tyle może zrobić właściciel bazy ze swoją bazą:

Kod:

ejabberd=> select * from users;
ERROR:  permission denied for relation users

I jak to zwykle bywa, im więcej człowiek czyta o danym problemie, tym większy ma bajzel  w głowie, bo wszystkie tutki, jakie widzę ograniczają się do podstawowych podstaw opisujących podstawy podstaw, ale już kwestia uprawień jest tam opisana tak, ze co tutek to inna wspaniała recepta - wszystkie do dooopy.
Żeby było weselej, dotyczą domyślnej konfiguracji PGSQL z autoryzacją trust po localhoście, i sytuacją, kiedy praktycznie wszyscy do wszystkich baz mają dostęp.

W dodatku cały net pełny jest przepisów na PGSQL-8,x a ja mam 9.3 obecnie, co tym bardziej sprawy nie ułatwia.

Zapodaj to:

GRANT ALL PRIVILEGES ON TABLE moja_tabela TO ejabberd;

pgadmin-III i psql są OK reszta jest psu na budę.

Ostatnio edytowany przez debianus_userus (2014-07-20 17:57:45)

Zapodaj to:


pgadmin-III i psql są OK reszta jest psu na budę.

Przy 30 tabelach po jednej?
Nie da rady zrobić akcji w typie:

GRANT ALL PRIVILEGES ON ALL TABLE IN ejabberd  TO ejabberd;

???????????????

W tym strasznym, okropnym i lamerskim  Mysqlu to 60 sekund bardzo ciężkiego mieszania herbaty i parę ruchów myszką, albo jednego poleconka GRANT, i wszystko działa, bo GRANT na bazę jest dziedziczony na wszystkie elementy składowe bazy.

Natomiast tutki do Postgresa poznaje po tym, że temat uprawnień do baz jest tam tak ujęty, jakby w ogóle nie istniał.
Tymczasem Postgres, jeśli ma być serwerem dostępnym w Necie, i działać z usługami w necie, to musi być skonfigurowany równie starannie, jak Mysql, bez żadnych trust w pg_hba.

Zwłaszcza, ze ma jeszcze wystawić port 5432 do replikacji i zdalnego dostępu, ale to już najmniejszy problem, pg_hba trudne nie jest, choć o certach SSL klienta (certy X509 lub PKCS12) w dokumentacji nic konkretnego nie widziałem na razie, a po wpisaniu cert zamiast md5 w pg_hba.conf Posgres u mnie nie wstaje w ogóle.

Żeby zrozumieć, dlaczego ponad 75% skryptów typu forum, sklepów internetowych i CMSów bazuje na Mysql, to trzeba się ze dwa dni pobawić Postgresem. xD

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-07-20 18:13:56)

Zobacz czy to pójdzie ??

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO ejabberd;

http://www.postgresql.org/docs/9.3/static/ddl-schemas.html

Piszę z głowy bo nie mam postgresa pod ręką.

Ostatnio edytowany przez debianus_userus (2014-07-20 18:25:13)

psql nie ma czytać konfigów tylko łączyć się z serwerem.
przestań zachowywać się jak windziarz.
linux jest inny niż wundiws - ergo jest gorszy.
postgres jest inny niż naszaklasa - ergo jest gorszy.
to samo pewnie powiesz o oraclu czy mssql?
po kim jak po kim - ale po Tobie takich tekstów się nie spodziewałem.

wciórności, nie wypowiem, kumie Barbaronie...
masz takiego śmiesznego postgresa gdzie nie ma alter table?
nie przesadzam.

ALTER TABLE jest, ale ani ten Postgres, ani autor postu powyżej nie podpowiedzieli, jak się tego używa w kontekście np uprawień.
Wiem tylko, jak się przy pomocy tej funkcji zmienia hasła w Postgresie.

Jacekalex napisał(-a):

ALTER TABLE jest, ale ani ten Postgres, ani autor postu powyżej nie podpowiedzieli, jak się tego używa w kontekście np uprawień.
Wiem tylko, jak się przy pomocy tej funkcji zmienia hasła w Postgresie.

Zobacz tu:

http://www.postgresql.org/docs/9.3/static/sql-alter … ivileges.html

Jacekalex napisał(-a):

wygląda trochę lepiej od Firebirda, ale gorzej od Mysqla/Mariadb/Percona.

a) bazy danych nie są od wyglądania.
b) coś wspominałem o windowsie i linuksie?
c) porównaj z oraclem, mssqlem, db2 - wtedy pogadamy

Znalazłem ciekawy tutek dotyczący bezpieczeństwa Postgresa,
który przewiduje usunięcie wszystkich uprawnień z roli PUBLIC.
http://www.mad-hacking.net/documentation/linux/appl … rmissions.xml
I jeszcze ciekawszy artykulik:
http://www.ibm.com/developerworks/library/os-postgresecurity/

Sam się zastanawiam, czy nie spróbować całkowicie usunąć domyślnej roli PUBLIC (o ile to wykonalne), i ciekaw jestem, czy to oznacza całkowite zniszczenie Postresa, czy tylko jego mocniejsze  zabezpieczenie.

Pomysł wziął się jak zwykle z Mysqla, gdzie pacjent domyślnie nie ma prawa sprawdzać uprawnień innych pacjentów, a tym bardziej zaglądać do do listy nie swoich baz i tabel.
Czyli coś w tym guście:

mysql -u ejabberd -phaselko

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| ejabberd           |
| ejabberdold        |
+--------------------+
3 rows in set (0.02 sec)

MariaDB [(none)]>

Pozdro

Ostatnio edytowany przez Jacekalex (2014-07-21 01:57:37)

Już sobie z tym poradziłem, ale dzięki ;)

Po prostu wystarczy, żeby to pacjent robił tabele, a nie inny user, wtedy uprawnienia są prawidłowe OTB.


Raczej interesuje mnie zabezpieczanie Postgresa, żeby pod względem uprawnień, kontroli dostępu i ujawniania pacjentom info o innych pacjentach i ich uprawnieniach,  podciągnąć  go do poziomu  Mysqla (cokolwiek miałoby to znaczyć). :D

Ostatnio edytowany przez Jacekalex (2014-08-12 08:12:29)