Pomoc Zarządzanie użytkownikami dla wielu aplikacji

spietrza

Download Station
Q's Professional
20 Marzec 2013
428
83
118
48
Poznań
QNAP
TVS-x71
Ethernet
802.11ad
Witam wszystkich,

zaczynam się trochę irytować formą zarządzania użytkownikami w QNAP-ie i aplikacjach trzecich producentów.
Dokładnie chodzi mi o to że utworzeni użytkownicy na serwerze mają nic do aplikacji dodatkowych uruchamianych na serwerze.

Dostęp do panelu jedna baza, pyload druga baza, virtualka trzecia baza, rtorrent, pretashop kolejna i tak dalej. No kurde zarządzanie 3-4 bazami dla docelowo 10-30 użytkowników dla każdej aplikacji to koszmar.
Czy jakikolwiek użytkownik próbował zintegrować wszystkie bazy w jedną lub dwie dla bezpieczeństwa ?? Znacie może metody do ulepszenia tego procesu utrzymania kilkunastu baz???
 
Dokładnie chodzi mi o to że utworzeni użytkownicy na serwerze mają nic do aplikacji dodatkowych uruchamianych na serwerze.
Ale to chyba nie wina systemu QNAP albo samego Linux/Unix'a no nie?
Tylko autorów aplikacji...
Albo jedno i drugie...

Dostęp do panelu jedna baza, pyload druga baza, virtualka trzecia baza, rtorrent, pretashop kolejna i tak dalej. No kurde zarządzanie 3-4 bazami dla docelowo 10-30 użytkowników dla każdej aplikacji to koszmar.
Bzdura nigdzie tak nie ma.
Dopóki nie używasz systemu jako środowiska do hostowania usług/aplikacji na świat, dopóty możesz używać poświadczeń systemowych.

Przykład: Scenario 1)
Uruchomiasz dla firmy usługę serwerową do której dostęp mają użytkownicy z sieci lokalnej firmy. W ten moment dobrze jest zintegrować użytkowników systemowych i poświadczenia dla wybranych aplikacji z centralną bazą użytkowników LDAP lub Windows Active Directory.

Przykład: Scenario 2)
Uruchamiasz Linux'a jako środowisko, które ma udostępniać usługę z przeznaczeniem publiczym na świat - targetowaną dla miliona userów z Internetu. W ten moment błędem byłoby ich łączenie z poświadczeniami systemowymi, uprawnieniami plików, itp. Dla takich aplikacji, najlepiej całkiem odseparować usługę od systemu, a dla zwiększonego bezpieczeństwa uruchomić ja na chroot'ie.
Przykład: glftpd - serwer ftp stosowanych na sitach warezowych, uruchamiany na chroot'ie. Site'y warez = środowisko crackerskie, tym samym niedaleko im od hakierów. Uruchomienie usługi na chroot'ie to jedyne sensowane wyjście, a już w ogóle najlepiej na wirtualce.
Glftpd - Wikipedia, the free encyclopedia
glFTPd :: We make files transfer!

Czy jakikolwiek użytkownik próbował zintegrować wszystkie bazy w jedną lub dwie dla bezpieczeństwa ?? Znacie może metody do ulepszenia tego procesu utrzymania kilkunastu baz???
Chciałbyś, aby dla wszystkich producentów aplikacji trzecich przyznawano uprawnienia z poziomu systemu?

Musiałbyś pisać do producentów wszystkich tych aplikacji o zmianę obecnego zarządzania użytkownikiem i dodanie jej w oparciu o systemowe poświadczenia kompatybilne z listą z /etc/passwd i grupami z /etc/shadow.

Napisz do autorów wymienionych aplikacji o integracje użytkowników z systemem Linux/Unix. Dla ułatwienia podpowiem Ci, że od tego jest biblioteka libpam a dokładniej moduł pam_unix.
Ref.: The Linux-PAM System Administrators' Guide

Ale ...
Nikt Cię nie posłucha ponieważ userzy aplikacji mają mięć się nijak do userów systemowych o czym wspominałem wcześniej. Gdyby któryś z autorów jednak zechciał Cię posłuchać i poszedłby tą sugestią, to uniemożliwiłby uruchomienie swojej aplikacji na shellu bez uprawnień root'a.

FYI: Jedyne profesjonalne aplikacje jakie znam i działają w oparciu o poświadczenia systemowe, to te, które są pisane jako usługi działające pod powłoką Microsoft Windows Server - nie Linux'a! Do tego należała kiedyś Macromedia, Adobe, Autodesk, Mileston, Citrix, ... i miliony innych profesjonalnych producentów.
Bo Linux to świat... Biedny!
Linux'a świat piszą programiści z wiedzą na poziomie programowania w Basic'u. Może 20% z nich włada ala Turbo Pascal 2 dekady temu, a jeszcze 3% z nich może potrafi klepnąć Hello World w C++.