Thema:

Kommentar:
: Hi Folks! : Bin gerade dabei mehrere Unix Plattformen (AIX + SAP R/3 und Sun/Solaris + Data Warehouse) für Produktionsbetrieb einzurichten und stoße auf seltsame DB2 Datei-Autorisierungen (file authorizations): : Backups und Logs werden mit der Maske 640 (Read/Write für Owner, Read für Gruppe, nix für other, oder sogar noch restriktiver) eingerichtet. D.h., im laufenden Betrieb dürfte nur der Datei Owner = DB2 Instance User die Files löschen. Warum löschen? Na, irgendwann sind Backup- und Log-Dateien halt veraltet und können gelöscht werden. Das ist gerade bei SAP R/3 Full Backups sehr interessant - weil riesig!!! : Nun ja, IBM war der Meinung, daß diese Maskierung ok sei - kein anderer als der DB2 Instance User könne über die Löschung entscheiden. "Works as designed!!!" Somit kann also kein Mitglied der SYSADM_GROUP (siehe Database Config Parms) die Dateien löschen, obwohl solch ein Mitglied die Database droppen könnte?!?!?! : Es gibt (zufällig bemerkt) einen Work-Around: Wenn man dann jeweiligen Pfad autorisiert mit z.B. 770 (RWXRWX---), dann kann ein Gruppen-Mitglied der Instance User Group wenigsten die Dateien löschen. Andere Möglichkeit: Programm/Script mit S-Bit! : Gruß : Gernot : PS: Noch seltsamer wurde das Ganze, als ich die Database Path Authorization auf die Maske 770 (RWXRWX---) für DB2 Instance User und seine Gruppe setzen wollte. Zweck: Kein anderer als DB2 Admins sollten auf den Unix-Servern Datenbank-Datein lesen dürfen! ABER: Dann konnte sich kein User, selbst kein autorisierter DB2-User mehr verbinden/connecten!!! Warum? Jeder User braucht auf Datei-Ebene immer noch Read-Zugriff. : Oh IBM, wie peinlich. Public User die Read-Zugriff (7x4=RWX???R--) brauchen? Eine riesen Sicherheitslücke!!! "Works as designed!"

Optionale Link URL:   
Link Titel:                  
Optionale Image URL: