Fejlesztői jog a log-okhoz (hogy illik?)

Red Hat, Fedora, CentOS

Adott CentOS szerver a szokásos 2 havi httpd frissítésel. Ez egy fejlesztői szerver, ahol a /var/log/httpd-t ki szoktam ajánlani megtekintésre (kapnak rá Read+Execute jogot), hogy a hibákat könnyebben ellenőrizhessék. A httpd frissítések után ezek a jogok bezáródnak és újra ki kell nyitni.

Nem vagyok lusta (de!), csak kíváncsi, hogy ezt hogy illik megcsinálni?
- symlink a könyvtárra az user home-jába (vag az sem menne a jogok miatt?)
- valami log-sync, ami átpakolja a publikus logokat?

Köszönöm a láma kérdésemre adott válaszotokat.

  • 4790 megtekintés

( uid_4672 | 2017. 10. 24., k – 09:17 )

a symlink csak akkor megy, ha a /var/log-hoz amúgy is van hozzáférése a juzernek.
Az adm group pont azért van, hogy a tagjai tudják monitorizálni a rendszert/logokat nézni.

én betenném a http usert az adm groupba, besymlinkelném a /var/log/httpd-t és biztosítanám, hogy ne tudjon máshoz hozzáférni.

#facepalm

Miért nem rögtön root? Vagy wheel? Jogot nem úgy adunk, hogy "ez tartalmazza azt is, amit kérsz, nesze, itt van", hanem a minimálisan szükséges, de nem több jogot adunk meg az egyes felhasználóknak/csoportoknak.
Nehéz jól megoldani, de nagyon sok esetben szükséges.

Logot nézegetni egyébként sudo -u logtulaj view /var/log/blabla/bla.log módszerrel is lehet - a usereket, akik használhatják, belerakni egy csoportba, amihez sudoers-ben beállítod, hogy logtulaj user nevében futtathatnak pontosan megadott parancsokat.

te tudod, hogy mire jó az adm group? és ugye nem téveszted össze az admin group-pal?

az adm group pont erre van: logokat nézegeni, nem többet. A /var/log folderben, ahol amúgy is van egy csomó world readable log file.

Nem kell trollkodni, hogy akkor miért nem egyből root...

szerk: főleg, hogy egy development szerverről van szó

( sj | 2017. 10. 24., k – 09:20 )

A httpd frissítések után ezek a jogok bezáródnak és újra ki kell nyitni

ez a mondat mit jelent magyarul?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( lovagX | 2017. 10. 24., k – 09:59 )

http logoljon syslog-ngbe.
syslog-ng meg kepes masik dirbe, mas jogokkal tolni a logokat.

+1

Szerintem egy kicsi, adott projektre dedikált dev szerveren ez a legegyszerűbb és legpraktikusabb megoldás. Mivel épp a napokban kellett valami ilyesmit kialakítanom, gondoltam, leírom, hogyan oldottam meg egy Debian 7-es LAMP szerveren:

1. Az rsyslog konfigjában össze kell rendelni a facility-ket és severity-ket a megfelelő logfájlokkal:

## rendszerszintu error log - az apache csak egy ErrorLog direktivat tud kezelni vhostonkent, igy ezt is innen oldjuk meg
if $syslogfacility-text == 'local7' and $syslogseverity-text == 'error' and $programname == 'httpd' then /var/log/apache2/domainnev.tld-error.log

## error es access log a fejlesztonek, megfeleloen beallitott jogosultsagokkal
$FileOwner kispista
$FileGroup users
$FileCreateMode 0640
if $syslogfacility-text == 'local7' and $syslogseverity-text == 'error' and $programname == 'httpd' then /home/kispista/logs/domainnev.tld-error.log
if $syslogfacility-text == 'local7' and $syslogseverity-text == 'error' and $programname == 'httpd' then ~
if $syslogfacility-text == 'local7' and $syslogseverity-text == 'notice' and $programname == 'httpd' then /home/kispista/logs/domainnev.tld-access.log
if $syslogfacility-text == 'local7' and $syslogseverity-text == 'notice' and $programname == 'httpd' then ~

2. Apache konfigurálás (vhostonként lehet variálni):

ErrorLog "|/usr/bin/logger -t httpd -p local7.error"
CustomLog ${APACHE_LOG_DIR}/domainnev.tld-access.log combined
CustomLog "|/usr/bin/logger -t httpd -p local7.notice" combined

A local facility 0-tól 7-ig van számozva, így ezzel a módszerrel max. 8 virtualhost logjait lehet több felhasználó számára is hozzáférhetővé tenni. Ha ennél több vhost van, akkor a facility helyett a $syslogtag-re (= a logger parancs -t kapcsolójában megadott szöveg) is rá lehet szűrni.

( dentzol | 2017. 10. 24., k – 10:03 )

Központi logszerver és webes frontend bevezetésén is érdemes elgondolkodni.

( bucko | 2017. 10. 24., k – 10:36 )

Ilyet acl segíségével csinálnék.
Ez a megoldás nem sérti meg a rendszerben beállított általános jogosultságokat.
Ha a frissítés ezt is felülírná, akkor kell egy frissítést frissítő script. ;)

( ha4bf | 2017. 10. 24., k – 10:45 )

A lustaság fél egészség... sok vizet nem zavar.

groupadd developers; usermod -G developers fejleszto1

cron-ba:
0 5 * * * setfacl -m g:developers:rx /var/log/httpd; setfacl -m g:developers:rx /var/log/httpd/*

--
Feri

( Elbandi v | 2017. 10. 24., k – 11:31 )

a legtobb webkiszolgalo proginak (apache/lighttpd/nginx biztosan) meg lehet adni hova pakolja a logokat, akar vhostonkent kulon-kulon. tedd az user konyvtaraba (de ne a webroot-ba!) a logokat.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

tehat azt mondod, hogy a belso halon nem gond, ha security problemakat csinalunk? Ez meglehetosen erdekes hozzaallas annak fenyeben, hogy - allitolag - a biztonsagi incidensek 80%-a belulrol jon, bar mar regen olvastam ezt a cikket, szoval azota biztos ez a szam leesett 0-ra.

Masfelol, ha egy ilyen basic taszkot ilyen duplatenyeresen, boszme modon oldunk meg, akkor elore felek, hogy ennel komolyabb es osszetettebb dolgokat vajon hogyan oldanak ott meg...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

ok, game on. Allitsuk be azt, hogy az access.log a /home/bela/log/access.log-ba keruljon. bela latja a sajat logjait, mindenki boldog.

De bela ennel tobbet is tehet. Mi van, ha kiprobal egy ilyet:

mv log log2
mkdir log;
chmod 777 log (esetleg 1777)
ln -sf /etc/passwd log/access.log

Na ebben az esetben mi fog tortenni? Ha be van allitva logrotate is erre a logra, az plusz egy mokas faktort hoz be.

Olvasnivalo: https://httpd.apache.org/docs/2.4/misc/security_tips.html#serverroot

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...


# chmod 1777 log
# sudo -u www-data sh -c 'echo test >/log/access.log'
# rm log/access.log
# ln -sf /etc/passwd log/access.log
# sudo -u www-data sh -c 'echo test >/log/access.log'
sh: 1: cannot create /log/access.log: Permission denied

:( 


# logrotate -d /etc/logrotate.d/test
reading config file /etc/logrotate.d/test

Handling 1 logs

rotating pattern: /log/access.log  hourly (12 rotations)
empty log files are not rotated, old logs are removed
considering log /log/access.log
error: skipping "/log/access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

:( 


# chmod 770 log
# logrotate -d /etc/logrotate.d/test
reading config file /etc/logrotate.d/test

Handling 1 logs

rotating pattern: /log/access.log  hourly (12 rotations)
empty log files are not rotated, old logs are removed
considering log /log/access.log
  log /log/access.log is symbolic link. Rotation of symbolic links is not allowed to avoid security issues -- skipping.

:(

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

# sudo -u www-data sh -c 'echo test >/log/access.log'
sh: 1: cannot create /log/access.log: Permission denied

ez egyaltalan nem ugyanaz, mint amikor a webszerver root-kent indul el, es nyit meg file-okat, etc. De linkeld csak ra a /etc/passwd-re, aztan meglatod...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( Jason v | 2017. 10. 24., k – 13:28 )

A fejlesztők utálni fognak be-ssh-zni random faszom gépekre és cd/ls/grep/vim/lófaszkodni.

Nézd meg a Splunk-ot.
Esetleg New Relic vagy AppDynamics, de ezek már monitoring tool-ok, nem sima logban kereső baszok.

( lberes (nem ellenőrzött) | 2017. 10. 24., k – 16:13 )

Nemreg lattam olyan, hogy apache logok a /tmp-be, world readable jogokkal, hogy mindenki lassa a debug soran a naplofile-ba kerulo neveket, privat cimeket es ilyesmiket - mekkora otlet :)

--
L

( hory v | 2017. 10. 25., sze – 00:03 )

Mivel manapsag mar ugye senki se futtat failover/load balance nelkul szervert (ugye?!), a logok aggregalasahoz javallott egy kibana.
Bonuszkent frankon keresheto, es a szerverfarm bovulesekor abszolute nincs gond.
Ja es microservice-k eseten is hasznos.

( Nyosigomboc v | 2017. 10. 25., sze – 00:08 )

Gondolom virtualizalva van az a dev server, es csak az van rajta, ami ahhoz a konkret projecthez kell. (Ha nem, az baj.)
Akkor megkerdezheted a fejlesztoket, hogy ok hogy szeretnek elerni a logjaikat. Akar root jog is adhato valamelyiknek, aki ert hozza, es nem fogja elrontani (bar ha elrontja, visszahuzod backupbol/rollbackeled a snapshotot).

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

A kep megerdemli a like-ot.

Viszont a fejlesztok homokozojaban nyugodtan robbanthatnak, minimalis kart csinalhatnak (ld. rollbackeled). Ami problemat latok, az az, ha a belso halot eleri, es ezen keresztul egy tamado bejuthat, de ezt meg le lehet tuzfalazni.
Eles/test serverre meg valoban igaz, ami a kepen van.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

a termeszetben egyensuly van torveny alapjan nyilvan vannak olyan fejlesztok, akiktol nem kell felteni a dev rendszert. Mondom, nekem az az alapveto bajom a logokat a user home-ba tenni, adm group-ba betenni a www-data usert es hasonlo boszmesegekkel, hogy ha ilyen kis dolgot igy oldanak meg, akkor aligha valoszinu, hogy egy komolyabb feladatot kepesek lennenek korrekten megoldani, anelkul, hogy egy jobb erzesu rendszergazda zokogasban ne torne ki...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( yorkeetech | 2017. 10. 25., sze – 09:13 )

Gondolom webfejlesztés plusz egyszerre több alkalmazás is van a szerveren, nem lenne egyszerűbb a logokat eleve virtualhostonként szétválogatni? Ha meg nem akaródzik konfigokat szerkeszteni, ISPconfig meg hasonló jópofa alkalmazások ezt megoldják.
Csak tipp volt :)

----------------
Bruce Lee

( tigrincs | 2017. 10. 25., sze – 10:57 )

Olvasva egy ket tanacsot ennek a topicnak egy haszna van:

Legalabb megcafoltuk azt a tevhitet ,hogy minden Linux user admin atyauristen es erti ,hogy mit csinal az OS-en hiszen consolban potyoreszik mint Trinity...

( dotnetlinux | 2017. 10. 26., cs – 08:43 )

Huhhh, köszönöm a sok remek hozzászólást, sokat tanultam belőle. :)

A szerver maga egy kívülről is elérhető web-es fejlesztőszerver. Webes projekteket fejlesztünk ott és web alapú az eszköz is (forrásfájl kezelő, db manager, task manager, package manager). Bárhonnan be lehet lépni böngészővel, nem kell a developer gépekre semmilyen eszköz. A fejlesztők nem is lépnek be SSH-val, nincs is userük, épp ezért volt fontos, hogy a log-okat az apache tudja olvasni HTTPD csomag frissítése után is. A webes kiszolgáló kiszolgálja a fejlesztőeszközt és a vele készült projekteket is DEV szinten. Amikor minden jó, akkor meg tovább teszt-re és élesbe.
Már sok helyről megkaptam, hogy minek ekkora túllövés. A cég vezetője ezt is egy projektnek gondolja, nem csak megrendelés alapon dolgozunk, hanem néha saját "szórakozásra" is.

"http logoljon syslog-ngbe": nem akkora a projekt, hogy ez ne lokálisan legyen megoldva.

"Failover/load balance": ez ide tényéleg sok lenne, ez nem a TEST-server, csak a DEV

"Ha ez szerver a fejlesztők játszótere nem akkora probléma (ha nem érhető el csak belső hálón)": elérhető kívülről is, ezért nem nyitogatunk csak úgy logokat.

"Legalabb megcafoltuk azt a tevhitet ,hogy minden Linux user admin atyauristen es erti ,hogy mit csinal az OS-en": ha másra nem, erre jó volt :) Mertem kérdezni :)

"Failover/load balance": ez ide tényéleg sok lenne, ez nem a TEST-server, csak a DEV

Ismet: arra valo a fejleszto sajat gepe. Ehhez nem kell kulon szerver.
Plane manapsag, amikor docker/vagrant vagy csak siman helyben futtatva barmit konnyeden ossze lehet rakni.

lasd meg: joel test, 'can you build/run in one step' ?

-1
Hoppá, ez a pár modat le is írta az összes hibás fejlesztési szokást!
Úgy gondolom, Joel minden betűje aranyat ér - kortól függetlenül. De 17 évvel ezelőtt - még a Moore törvény ismeretében sem - nem láthatta, hogy hova jut ma a világ. Ezért kiegészíteném egy 13. ponttal:

13. Sok nyugtatót szed-e a fejlesztő?

Magyarázat: Ki kell alakítani egy teszt környezetet - akár a fejlesztő saját gépén, amelyen legalább 1000x lassabban fut a fejlesztés alatt álló entitás. Ha a fejlesztő nem szed sok nyugtatót, nos akkor sokkal jobb szoftverek készülnének.

"Ismet: arra valo a fejleszto sajat gepe. Ehhez nem kell kulon szerver."

A praktikumot néha felülírja egy ideológia, pláne ha az kellően felülről jön. Az ötlet az volt, hogy bárhonnan lehessen fejleszteni, a fejlesztő (apache) és futattó/repo környezet (apache) ugyanaz legyen és együtt legyen a checkout/checkin felülettel.

És ezt a webes környezetet egy HP Envy360 (I7, 16GB ram...) géppel érem el. 2 példány Chrome, az egyikben egy fül, a másikban 2-8 fül... Na ez a túllövés :)

'can you build/run in one step': pont ez a lényege is, mentés, commit és rögtön lehet TEST/PROD package-et is csinálni.

Az ötlet az volt, hogy bárhonnan lehessen fejleszteni, a fejlesztő (apache) és futattó/repo környezet (apache) ugyanaz legyen

es ezert kell a dev rendszert kitenni a netre es a belso halora is? Btw. erre 2017-ben vannak azert mar jobb modszerek is, pl. virtualis gep (mondjuk image-bol telepitve), docker.

A masik dolog, hogy a repo-t (is) pl. vpn-en keresztul is el lehetne erni. Mert van egy olyan erzesem, hogy a repo-tokra is be lehet latni a net felol...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

A repoba be lehet látni, mert ki kell tudni próbálni távolról is :) A VPN "helyett" van szűrés Telekom IP-kre (tudom, láma dolog).

Egy dolog kimaradt, ami miatt nem megoldás a csillagháborús terv: napon belül 1-3 projekthez is hozzá kell nyúlni, a közös teszk kezelő miatt a fejlesztőszerver közös.

A VPN "helyett" van szűrés Telekom IP-kre (tudom, láma dolog).

ja, hat vegul is, a telekomos ip-kre szures (sok sikert hozza, btw. tudod, hany halozatuk van? :-)) az a szegeny ember vpn-e :-)

Tuzfalatok nincs? Nem tamogat mondjuk valamilyen (pl. IKE IPSec) vpn-t?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

A fejleszto gepen IDE kell, nem teljes kornyezet.
Commit; push; fut ra rogton a CI; failfast; visszajelez repo commitra+chatre+email hogy jo-e a unit+comp test+build+code quality
Ha van ra igeny akkor elindit belole egy peldanyt es szol, hogy hol ered el. Ha jon ugyanarra a branchre commit akkor az elozot lelovi stb stb bla bla bla

( kisg v | 2017. 10. 26., cs – 19:36 )

1. Telepíts Kubernetes-t (igény szerint más container rendszert is használhatsz, de minek)

2. Fejlesztők felé jelezni, hogy mostantól Kubernetes alkalmazásként lehet deployolni, javaslod, hogy helm chartként definiálják. Logoláshoz tanulmányozzák ezt: https://kubernetes.io/docs/concepts/cluster-administration/logging/

3. Kubernetes clusterre fel kell tenni Elasticsearch-öt + Kibana-t, és azt beállítani logok gyűjtésére:
https://kubernetes.io/docs/tasks/debug-application-cluster/logging-elas…

Ha ez a paradigmaváltás túl sok (bár egyelőre úgy néz ki, hogy ez a jövő), akkor lehet csinálni kicsiben docker-rel, és ott is hozzá tud a fejlesztő férni az általa deployolt containerek logjaihoz.

( sigellef | 2017. 10. 27., p – 12:33 )

A webfejlesztőt olyan csoportba kell rendelni, akinek joga van a webserver /var/log -ját olvasni.
Esetleg 2 felhasználói fiókot adni neki, 2 terminállal bejelentkezhet, az egyikkel webfejleszt, a másikkal logokat olvas. Ha ügyes a webfejlesztő, így akár azt is megoldhatja, hogy "realtime" láthatja a generálódó hibákat.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( gelei v | 2017. 11. 03., p – 20:12 )

Ki kéne adni a threadben összegyűjtött security antipatterneket könyv formában is, hogy az utókor tanulhasson belőle.

( Protezis | 2017. 11. 03., p – 20:54 )

Splunk? Nálunk így szokás, bár nagy projekt, multi.