Volt ilyen (terminálban)?

sudo ufw enable

Ezt futtatva minden rendszer indításnál elindul.
Gondolom, a grafikus felület is szabályozza ezt, nem néztem rá. Én mindig indítom a folyamatot előtte, elméletileg ez a hivatalos engedélyezés.

Állapot lekérdezés itt:
https://linuxmint.hu/comment/41158#comment-41158

#4 Nem találkoztam még a problémával (UFW). Miért volt erre szükség?

-A WARN üzenetekek kivétel nélkül valami hibás jogosultság beállításról szóltak, valamelyik, vagy több rendszermappára írási joga volt mindenkinek. Nálam pl. a gyökér mappa volt ilyen.

Főként az a problémám, hogy nem tudom, mi a célja a csak futólag, pontosan nem közölt „bizonyos” rendszerkönyvtárak jogosultságat megváltoztatni, de symlinkkel is csodálatosan meg lehet oldani jó pár dolgot, ezáltal nem az eredeti könyvtárat piszkálod. Ha admin joggal kezelhető alkalmazások kezelése a cél, akkor a felhasználó kerüljön bele a sudo csoportba. Valami PHP-s történet vagy NGinx szerverről van szó, esetleg nyomtatás...?

Neked - a telepített rendszer fő felhasználójának - a rendszer (gyökér) könyvtár kezeléséhez alapvetően jogod van, nem kell ahhoz (nem ajánlott) annak tulajdonságait megváltoztatni... (admin jog = sudo a Debian-alapú rendszereken). Pontosítsuk, mi szükséged volt erre, hogyan, milyen lépésekkel csináltad (parancssor, fájlkezelő, stb.), így talán megértem, mi volt a célja. Lehet, kiselefánt vagyok... ;)

Egy vagy több WARN üzenetet -  a személyes adatok kimaszkolása után - mutatnál?

#3

Volt ilyen (terminálban)?

sudo ufw enable

Ezt futtatva minden rendszer indításnál elindul.

Volt hát. Meg mindenféle. Arról van szó, hogy mindez hatástalan, ha az UFW valami jogosultság problémával találkozik, akkor leáll.

#6 Értem. Az idő és a tapasztalat engem is irányítgat a jó felé. :D
Nézegetem ezeket majd, de pontosan meg kéne tudni, mely könyvtárak lettek írhatóak a WARN szerint. Mert nem mindegy, lehet sajátosság is, például egy szervernél (szerver alkalmazás használatakor). Gondolom, a probléma újra feltűnik majd, tehát „én” nem aggódom, hogy lesznek pontosabb WARN kimenetek. Ha lesznek, jobban rálátunk. Az én rendszeremen nem tapasztalható, de csak egyetlen felhasználó van.

Nem igazán használom „globálisan” rendszerkönyvtárra, sem rekurzívan (alkönytárakra, fájlokra) a chmod-ot, mert nagyon bele lehet bonyolódni. Tehát az itt említett dolgokat biztosan nem fogom megcsinálni:
https://askubuntu.com/questions/427870/how-to-fix-permissions-warnings-i...
Hasonlókat sem. Egyetlen fájlra vonatkozóan esetleg (chmod), de akkor is nagyon átgondolom. Ilyen volt a K3B esetén is egy-egy javaslatom itt. A globális változtatás elég veszélyes. Alapból ezt gondolom, hiszen nem ugyanaz a fájlok és könyvtárak jogosultsága, mint az ezeket tartalmazó fő könyvtáré, ... hanem eléggé változatos.
Összegezve: soha nem teszek ilyet. Egyszer mégis megtettem (írtam erről): a vágólapon volt egy rossz parancs (nem az utána, időrendben újabb másolt jót illesztettem be), fáradt voltam már, Entert nyomtam :). Az eredmény rendszer újratelepítés lett, semmilyen alkalmazást nem tudtam elindítani ..., pont azért nem futtattam volna a rossz parancssort, mert ránéztem még egyszer, gondolkodtam, és elsőre mégsem ütöttem Entert, hanem másoltam egy új parancsort (ennek kivitelezése nem sikerült).
Nem jogosultságot kell helyretenni (nem lehet így megoldani a problémákat), hanem a probléma okát megkeresni, és abból kiindulni. Ha nehezebbnek tánik, akkor is. Az alkalmazásoknak saját, beállított, azaz egyéni jogosultságaik vannak a fájlokra és a könyvtárakra. A rendszer-visszaállítási pont készítése, és a rendszer visszaállítás kiváló megoldás lehet átmenetileg. Addig, amíg a probléma oka kiderül, mert gondolom, újra is jelentkezhet, de kiváltó oka is van.

#5

Nem találkoztam még a problémával (UFW). Miért volt erre szükség?

>>-A WARN üzenetekek kivétel nélkül valami hibás jogosultság beállításról szóltak, valamelyik, vagy több rendszermappára írási joga volt mindenkinek. Nálam pl. a gyökér mappa volt ilyen.

Főként az a problémám, hogy nem tudom, mi a célja a csak futólag, pontosan nem közölt „bizonyos” rendszerkönyvtárak jogosultságat megváltoztatni

Ööö. Mindig lesújt, amikor azt látom, milyen gány a kommunikációs képességem, mea culpa.

Tehát, ez a dolog kb. véletlenüll, nem szándékosan, nem direkt, nem tudom mitől van. Pont ennek kinyomozása lenne a topic egyik célja. Tehát mintegy láthatatlanul ebbe az állapotba kerül a gép valamitől. Az én esetben volt a grub2  anomália, amit chroot-osan oldottam meg, a boot-repair-disk-el, és azt gyanítom, talán az kavart a jogosultságokkal. De volt akkor timeshisft visszaállítás is, még előtte. Ez csak tipp, tényleg nem tudom, és nincs időm teszteket végezni.

Egy vagy több WARN üzenetet -  a személyes adatok kimaszkolása után - mutatnál?

Nincsenek személyes adatok ezekben, de nem is tudok mutatni, mert már minden helyre lett állítva, de tudok mutatni példákat a netről. Itt csak annyi az eltérés, hogy nálam, kuncsaftoknál magyarul voltak az üzenetek, most viszont angolul kerestem rá, több találat érdekében:

https://duckduckgo.com/?q=ufw+WARN%3A+The+%27%2F%27+is+world+writable&t=lm&ia=web

https://duckduckgo.com/?q=ufw+WARN%3A+is+group+writable&t=lm&ia=web

 

#8 Talán ez is egy út lehet:
https://duckduckgo.com/?t=ffcm&q=ReadWritePaths%3D-%2Fetc%2Fufw%2F&ia=web
(https://security.stackexchange.com/questions/161962/setting-up-knockd-is...
https://stackoverflow.com/questions/44623860/setting-up-knockd-issues)
Ismétlem, nem megoldás, csak találtam egy ilyet (de nem ismerjük a kiváltó okot).
Több sorban is lehet: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863841

#7 Nálam nincs semmilyen hibaüzenet, a készenléti jelzés (prompt) tér vissza:

debkim@debkim:~$ sudo ufw enable
[sudo] debkim jelszava:
Firewall is active and enabled on system startup
debkim@debkim:~$ sudo ufw disable
Firewall stopped and disabled on system startup
debkim@debkim:~$ sudo ufw enable
Firewall is active and enabled on system startup
debkim@debkim:~$
debkim@debkim:~$ sudo ufw reload
Firewall reloaded
debkim@debkim:~$ 
debkim@debkim:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
debkim@debkim:~$

Olyan, amiket itt említenek:
https://raspberrypi.stackexchange.com/questions/87875/ubuntu-mate-ufw-er...
(Raspberry Pie)
A WSL-nél említik még:
https://stackoverflow.com/questions/36469527/installing-apache-on-window...

Arra gondolok még, a sudo csoport „nem tiszta”, az okozza a problémát:
https://forums.linuxmint.com/viewtopic.php?t=219721

Nálam a root felhasználó és a csoport a tulajdonos (és csak ő írhatja és szerkesztheti):

ls -la /etc/default/ufw
-rw-r--r-- 1 root root 1788 dec   14  2018 /etc/default/ufw

Láthatóan nincs ok erre:

WARN: /etc/default/ufw is world writable!

Nem megoldásokat közöltem, nem kell megcsinálni, amik a linkelt oldalakon vannak.

-----

A „world writeable” könyvtárakra keresés (5 könyvtár mélységben):

sudo find / -maxdepth 5 -type d -perm -777

... mindez fájlokra:

sudo find / -maxdepth 5 -type f -perm -777

Nálam nagyon kevés van.
Magyarázat: https://unix.stackexchange.com/questions/139764/what-are-the-world-writa...

#10 Sok sikert! (https://www.youtube.com/watch?v=mB3hvPqa_2g ;))

#9 Ismétlem, nem megoldás, csak találtam egy ilyet (de nem ismerjük a kiváltó okot).

Pont ez az, erre lennék én nagyon kíváncsi. Mindegy, majd figyelek, holnap megyek ismihez, megnézem a gépet ott is....

#12 Körülnéztem a neten, azóta már született a githubon bejegyzés az UFW hibáról, amit valamiért időközben le is zártak, bár azt nem sikerült kihámoznom, hogy milyen indokkal.

Még véletlenül se áruld el az URL-t!

#13 Ehhez később lapoztam le. Mmm, lehet nekik írni hibajelentést. És ez hogyan derült ki? Eset Sysrescue használat előtt még jó volt a rendszer, de a használat után már nem?

#12 És megvan az egyik gyanúsított, az Eset Sysrescue állítja el a jogosultságokat!

Amióta kezdő postot megírtam, árgus szemekkel figyeltem, persze, sikertelenül, aztán lankadt a figyelmem. Azonban, most egy általam használt notin megint észrevettem, hogy az UFW leállt, nem is tudom, mióta. Megint a győkér jogosultságai változtak meg, úgy hogy mindenki írási jogot kapott rá. A notin a kezdő poszt óta nem volt különösebb változás, csak a frisstések voltak telepítve. Emlékeim szerint, ami persze nem egy biztos pont.

Körülnéztem a neten, azóta már született a githubon bejegyzés az UFW hibáról, amit valamiért időközben le is zártak, bár azt nem sikerült kihámoznom, hogy milyen indokkal. Engem azonban jobban izgat a jogosultságok megváltozása.

Nem sikerül rájönnöm az okára. Arra gondolok, hogy mivel a jelek szerint erősen azokon a gépeken jelentkezik, amikkel kapcsolatba kerülök, valami olyan oka is lehet, ami az én szokásaimhoz is kapcsolódhat.

Ehhez viszont kellene egy olyan gép, amit hadrenbe állítok, és nem csinálok vele semmit, csak naponta bekapcsolom, és frissítem, majd megnézem, naponta, hogy mi a helyzet. Erre mostanában nem látszik esély....

#17 A változások listája (Changelog) elég érdekes történeteket rejt. (*)

#14 Az Eset Sysrescue viszont életembe nem  volt a kezembe. Ha jól látom ez egy live program.

Igen, az egy (jelenleg) Ubis live rendszer, az Eset vírusírtójával felszerelve. Arra jó, hogy "offilne" ellenőrzést biztosít, mármint nem a fertőzött rendszer alól van futtatva a víruskergető, amit esetleg semlegesíthet egy okos virnya.

#18 Nem igazán kóstolgatják a kérdést. :)

#16 Tessék itt van. Bár most látom, benéztem, ez group writable eset, nem world writable, meg a dátumot is, elég régi, de csak mostanában hozta fel a kacsa:
https://github.com/Microsoft/WSL/issues/383

Jah, és ez WSL is. :D
De a group writeable is hasonló eset. Kösz.

Itt lehet nyomonkövetni, ha vkit érdekel, azért így írtam, mert bár régebben voltak e-mail elérhetőségek is, most ettől elzárkoznak, telefonon meg nem akartam velük kommunikálni: https://forum.eset.com/topic/29423-eset-sysrescue-issue/

Legjobb a hibajelentő, annak nyoma marad, más is megtalálhatja. Kösz.
Regisztráltál is, vagy lehet névtelenül bejelentést tenni? Csak azért kérdezem, mert regisztrálás után feliratkozhatsz a változásokra, azaz a válaszokra. Mai napig kapom a LibeOffice makro-s kérdésemre a válaszokat (még nem oldódott meg). A GitHub / GitLab (valamelyik vagy mindkettő) értesít, ha változás van. Aham:

Home  > ESET General Forums  > Quick questions by guests (registration not required)

Mmm, én regisztráltam volna.

Az ESET SysRescue fő előnye abban rejlik, hogy az ESET Security az operációs rendszertől függetlenül fut, de közvetlen hozzáféréssel rendelkezik a lemezhez és a fájlrendszerhez. Ennek köszönhetően eltávolíthatók az általában (például az operációs rendszer futásakor) nem törölhető fertőzések. (*)

Túltolja. ;)

Leveleztem nemrég egy fejlesztővel, ígérte, megcsinál egy apróságot. Ha ideje lesz rá ... . Jó hosszú nyári szabadsága lehet :). Szinte mindegy amúgy, mert van más megoldás, és azt leírtam egy blogban. Nem lehet ráírni: - Öregem, mi van, mi van? Egyébként meg lehet lepni a fejlesztőket, ő sem gondolt arra, amiről írtam, de örült, és helyeselt is.

Hát az úgy volt, hogy szöget ütött a fejlembe az, amiket írtam, és megkérdeztem magamtól, miket szoktam én csinálni amúgy, amit a többség valószínűleg nem?

Igen, így kell. Azaz, gondolkodni. :)

Közben ellenőriztem a Avira Rescue System-et is, ez rendben van, nem állítja el a jogosultságokat.

Szuper!