Cunoștințe, prelegere, fișiere de configurare

Subsistemul de identificare

Subsistemul de conturi utilizează subsistemul de identificare. care în Linux are o structură modulară și se numește PAM (Module Pluggable Authentication, adică "Identificarea Plug-in-urilor"). Ideea PAM este de a unifica și, în același timp, de a face mai flexibile orice proceduri de autentificare în sistem - de la comanda de conectare la accesul la fișiere printr-un protocol, spune FTP. Pentru aceasta, nu este suficient doar să scrieți o "bibliotecă de identificare" și să forțați toate programele să o folosească. În funcție de identificarea. condițiile în care va avea succes pot fi mai mult sau mai puțin stricte și, dacă se va atinge, ar putea fi necesar să se efectueze acțiuni care nu au legătură cu definiția utilizatorului, ci mai degrabă cu instalarea sistemului.







În cele mai multe distribuții, PAM este instruit în schema ".d" și setările pentru fiecare serviciu care utilizează autentificarea. se află într-un dosar separat:

Exemplul 12.8. Plug-inuri pentru identificare (PAM)

În PAM, sunt identificate patru cazuri care necesită identificare. auth este identificarea reală. Determinarea faptului dacă utilizatorul este pentru care se eliberează el însuși - pentru a stabili dacă totul este bine în contul de utilizator, parola - schimbarea parolei în cont și sesiune - acțiuni suplimentare imediat înainte sau imediat după ce utilizatorul are acces la solicitarea serviciu. Aceste valori iau primul câmp din orice fișier de configurare din mem .d. iar în al treilea câmp este scris un modul. care verifică unele aspecte ale identificării. Cel de-al doilea câmp specifică modul în care succesul sau eșecul testării unui modul afectează succesul sau defecțiunea generală a acestui tip de identificare (de exemplu, înseamnă că în cazul în care modulul nu reușește, testul nu va fi finalizat). Al patrulea și ulterior câmpurile sunt atribuite parametrilor modulului:

Exemplul 12.9. Configurați PAM pentru conectare

O astfel de setare de autentificare a găsit Metodiu pe computerul său. În toate cele patru cazuri, se utilizează fișierul sistem-auth inclus (alte servicii sunt accesate la acesta), cu unele adăugiri. Astfel, în timpul identificării pam_nologin.so verificări suplimentare, dacă utilizatorii sunt conectați în general interzise (așa cum este cazul pentru câteva minute până când sistemul reporniri), și în fața sistemului și după eliberarea pam_console.so ei efectua operațiile descrise în capitolul 6, „transferul de drepturi deținerea de dispozitive "(și, în consecință, privarea de către utilizator a acestor drepturi).







Directorul / etc / pam .d este un exemplu minunat despre modul în care un profil definește comportamentul unui sistem. În special, primele patru linii de la sistem-auth arată că această distribuție folosește nu doar un fișier de parolă "shadow", ci o schemă TCB. descris în Capitolul 6. (După cum deja cunoscute Metodiu, în acest sistem în loc de totalul pentru toate / etc / fișiere de umbră implicate tip / etc / TCB / vhodnoe_imya / umbra. care drepturile de acces la acestea sunt aranjate în așa fel încât atunci când comanda passwd ar putea fără a schimba codul de utilizator la superuser).

Subsistemul jurnalelor de sistem

Toate evenimentele raportate de syslogd. sunt împărțite orizontal - în funcție de tipul de serviciu (facilitatea) cu care sa produs acest eveniment și pe verticală - în funcție de importanța acestuia (prioritate). Există aproximativ 20 de tipuri de evenimente (printre care autorul Daemon, kern mail, etc., precum și opt nume nenumite, de la local0 la local7). Gradele de importanță sunt doar opt, în ordine ascendentă: depanare. info. Notă. avertisment. ERR. Crit. alertă și apariție. Astfel, fiecare eveniment este definit de o pereche de valori, de exemplu, mijloacele mail.err pentru syslogd evenimentul asociat cu poșta și importanța nu mai puțin de eroare. Din aceste perechi (cu o posibilă substituție de tip sau importanță pentru "*", ceea ce înseamnă "orice" sau niciuna, ceea ce înseamnă "none"), fișierul de configurare /etc/syslog.conf este compilat:

Exemplul 12.10. Configurarea jurnalelor de sistem

În primul câmp al liniei, sunt indicate profilurile mesajelor separate prin simbolul ";", iar în al doilea - memorarea mesajului (fișier, terminal, există modalități de a le da spre prelucrare programului și a le trimite prin rețea). În exemplu, toate mesajele de importanță intră în fișierul / var / log / messages nu mai puțin decât notificarea. cu excepția mesajelor de tip mail și authpriv. Ei ajung acolo numai dacă au importanța cel puțin greșit. Mesajele de tip authpriv și auth de orice importanță intră în fișierul /var/log/security.log. dar de tip mail și importanță nu mai mică decât informația - la fișierul / var / log / maillog. Mesajele de tip emergent (cea mai mare importanță) sunt transmise tuturor terminalelor sistemului și, în final, toate mesajele sunt transmise la cea de-a 12-a consolă virtuală.

În multe sisteme, se utilizează un syslogd bine rafinat. permițând pentru a filtra mesajele, nu numai de tipul / importanța, dar, de asemenea, de exemplu, expeditorul, pentru a da exact (mai degrabă decât „nu mai puțin“) valorile de prioritate, și așa mai departe. n. Cu toate acestea, astfel de îmbunătățiri sunt necesare fie pentru a menține logare practic nefiltrată (obținută jurnalele de sistem complet de volum poate fi citit) sau devia fluxul unei anumite mesaje de serviciu într-un jurnal separat, din nou, nu pentru citire, cât și pentru prelucrarea ulterioară.

Merită menționat faptul că directorul /etc/syslog.d din versiunile mai noi ale syslogd este proiectat să stocheze fișiere de configurare non-profil în stilul ".d" și în prize. din care daemonul poate primi mesaje în același mod ca și din rețea sau ca rezultat al apelului de sistem syslog ().







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: