Puncte:0

Cel mai bun loc pentru executabilul pam_exec.so?

drapel cn

Am implementat un modul de autentificare conectabil (PAM) numit verificaConexiuni.

Am pus inițial acest executabil /usr/local/sbin/ deoarece Filesystem Hierarchy Standard spune că instrumentele de sistem instalate local merg în acest loc. Astfel, executabilul este folosit astfel

sesiune necesară pam_exec.so stdout /usr/local/sbin/checkConnections 10

Acest lucru funcționează bine, dar utilizatorii obișnuiți pot vedea acest executabil prin completarea filei, deoarece /etc/environment adaugă /usr/local/sbin la CALE.

Scopul meu este ca instrumentele mele de administrare a sistemului să nu polueze opiniile utilizatorilor obișnuiți. În mod implicit, aceștia nu vor vedea instrumentele mele de administrare a sistemului.

Mă gândeam să elimin folderele sbin din /etc/environment, dar https://askubuntu.com/a/866169/703866 recomandă împotriva asta.

Cel puțin nu ar trebui să eliminați niciuna dintre căile importante precum /bin, /sbin, /usr/bin și /usr/sbin din el.

Dacă pun checkConnections în altă parte, nu știu care este locul cel mai bun sau standard.

Vă rugăm consultaţi.

muru avatar
drapel us
Înțeleg ce încerci să faci, pur și simplu nu înțeleg *de ce*. S-au plâns utilizatorii dvs. de instrumentele dvs. de administrator de sistem care apar la finalizarea filei? Dacă nu, de ce rezolvi o problemă care nu există? Sau ești îngrijorat că vor rula aceste programe? Dacă da, de ce nu sunt remediate permisiunile? (În general, completarea filei nu arată comenzi pe care utilizatorul oricum nu le poate executa)
drapel cn
@muru vreau să învăț și să respect standardele. Dacă nu aș fi făcut asta, nu aș fi cunoscut standardul ierarhiei sistemului de fișiere. Dacă nu mi-ar fi păsat încapsularea, mi-aș fi marcat toate clasele ca „publice”.
muru avatar
drapel us
Ai standardele. FHS este perfect să păstreze aceste scripturi în `/usr/local/bin`. Și în unele limbi, totul este oricum „public”, iar încapsularea este o chestiune de convenții. Nu-ți poți aplica `public`/`privat`/orice la aceștia, acum, nu-i așa?
drapel hr
Dacă sunteți hotărât să faceți acest lucru, atunci cel mai apropiat candidat este probabil un subdirector pam sub [/usr(/local)/lib/](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html) (*„pot include, de asemenea, binare interne care nu sunt destinate să fie executate direct de utilizatori sau scripturi shell”*)
drapel hr
... există și [/usr(/local)/libexec/](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) (*"binare interne care nu sunt destinate să fie executate direct de către utilizatori sau scripturi shell"*). AFAIK, totuși, este mai mult o chestie de RH. Vedeți și [Care este scopul /usr/libexec?](https://unix.stackexchange.com/questions/312146/what-is-the-purpose-of-usr-libexec).

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.