MQTT in docker op Synology

[zunrob]

Ik draai al bijna een jaar MQTT in een docker op de Synology, en dat werkt prima. Heb deze opgezet via de GUI van Synology, en zelf de juiste mappen en config gemaakt.
Nu krijg ik na update naar 2.0.18 de melding dat o.a. de log en pasword file 'world readable' zijn en vanaf toekomstige versies niet meer gaan werken. Zoals gezegd tot nu toe alles via de GUI, en eigenlijk wil ik dat zo houden.
Het is me in dit geval niet helemaal duidelijk waar het probleem precies vandaan komt. Als ik via de Explorer kijk zie ik dat idd de admin groep als ook gebruiker 1883 rechten hebben. Maar ik kan niks wijzigen.
Ik ga liever niets met sudo doen. Kan iemand me de goede kant op wijzen?

[Septillion]

Heb je wat meer details? Zoals welke container gebruik je, is dat eclipse-mosquitto? Welke config van de container (volumes en ENV)? En wat heb je in de configvan Mosquitto?

En dat is een error in de log? Of zie je die ook ergens anders?

[zunrob]

Het is inderdaad de eclipse-mosquitto container.



Config:

code:

persistence true
persistence_location /mosquitto/data/
log_dest file /mosquitto/log/mosquitto.log
listener 1883
allow_anonymous false
password_file /mosquitto/config/password.txt
socket_domain ipv4

En in de log idd:

code:

1701724299: Config loaded from /mosquitto/config/mosquitto.conf.
1701724299: Warning: File /mosquitto/config/password.txt has world readable permissions. Future versions will refuse to load this file.
To fix this, use `chmod 0700 /mosquitto/config/password.txt`.
1701747712: Warning: File /mosquitto/data//mosquitto.db.new has world readable permissions. Future versions will refuse to load this file.
To fix this, use `chmod 0700 /mosquitto/data//mosquitto.db.new`.

Is idd alleen in de log te zien. Alles lijkt ook nog gewoon te functioneren.

[ Voor 19% gewijzigd door zunrob op 06-12-2023 11:50 ]

[Gizz]

zunrob schreef op dinsdag 5 december 2023 @ 22:04:
Als ik via de Explorer kijk zie ik dat idd de admin groep als ook gebruiker 1883 rechten hebben.

Die 1883 is de poort waarop Moquito luistert, dat is wat anders dan bestandsrechten. De bestandrechten werken volgens een octaal systeem, waarbij 7 het hoogste is. En je hebt 3 (soms 4) posities om de rechten van verschillende rollen weer te geven:



De foutmelding geeft dus aan dat alleen de eigenaar van het bestand lees, schrijf én uitvoerrechten moet hebben. Alle andere rollen krijgen een 0 en mogen dus helemaal niks, zelfs het bestand niet lezen.

edit: volgens mij kan je binnen File Station de rechten aanpassen als je niet in de console wil werken.

[ Voor 24% gewijzigd door Gizz op 06-12-2023 12:16 ]

[zunrob]

Gizz schreef op woensdag 6 december 2023 @ 12:11:
[...]

Die 1883 is de poort waarop Moquito luistert, dat is wat anders dan bestandsrechten. De bestandrechten werken volgens een octaal systeem, waarbij 7 het hoogste is. En je hebt 3 (soms 4) posities om de rechten van verschillende rollen weer te geven:

[Afbeelding]

De foutmelding geeft dus aan dat alleen de eigenaar van het bestand lees, schrijf én uitvoerrechten moet hebben. Alle andere rollen krijgen een 0 en mogen dus helemaal niks, zelfs het bestand niet lezen.

edit: volgens mij kan je binnen File Station de rechten aanpassen als je niet in de console wil werken.

Klopt, 1883 luistert ie, maar volgens mij wordt er standaard ook een gebruiker 1883 aangemaakt bij aanmaken van de container.
Als ik in File Station kijk naar de machtigingen van de log (en password file) zie ik het volgende (daar zie je ook de gebruiker 1883):


Ik kan echter niets aanpassen qua machtigingen. Vandaar ook de vraag.

Volgens mij zit het probleem hem erin dat de algemene machtigingen van de docker mappen worden bepaald door Synology/File Station. Deze container zelf maakt echter ook die gebruiker 1883 aan met zijn eigen rechten. Ik vermoed dat de melding 'world readable' nu komt doordat niet alleen 1883 toegang heeft (gecreëerd door de container zelf dus), maar ook de Synology admins (door de standaard Synology machtigingen). Ergens is dat natuurlijk logisch, en prima, behalve dat er in de MQTT container hier nu een controle op zit.

[ Voor 16% gewijzigd door zunrob op 06-12-2023 12:24 ]

[timovd]

Er staat toch letterlijk wat je moet doen? chmod 0700 van de twee bestanden.
Dit kan op twee manieren:
1. ssh naar je synology en inloggen met root.
maar omdat je alles via de GUI van Container manager hebt gedaan, verwacht ik dat dit een stap te ver is.
Andere oplossing is om een task aan te maken in task scheduler als root met het volgende commando:

code:

chmod 0700 /volume1/docker/mosquitto/data//bestandje

[zunrob]

timovd schreef op woensdag 6 december 2023 @ 12:28:
Er staat toch letterlijk wat je moet doen? chmod 0700 van de twee bestanden.
Dit kan op twee manieren:
1. ssh naar je synology en inloggen met root.
maar omdat je alles via de GUI van Container manager hebt gedaan, verwacht ik dat dit een stap te ver is.
Andere oplossing is om een task aan te maken in task scheduler als root met het volgende commando:

code:

chmod 0700 /volume1/docker/mosquitto/data//bestandje

Sudo gaat wel lukken verwacht ik, maar doe ik liever niet. Ook omdat ik ergens las dat op deze manier machtigingen aanpassen van een docker folder tot problemen kan leiden, omdat Synology in de basis die rechten anders beheert.

Ik vraag me namelijk af, of als ik die chmod doe, ik nog wel via File Station toegang heb (als gebruiker/admin) tot de log en password file. Ik kan namelijk niet als 1883 gebruiker inloggen op de NAS.

[timovd]

@zunrob backup (of schaduwmap) maken van de map en proberen. Werkt het toch niet, zet je de backup terug.

[Septillion]

Even zitten pielen hier, maar die container is gewoon idioot Wie gaat er nu met een andere user dan die de container draait files lopen aanmaken. En dan ook nog eens zeuren om zelf aangemaakte files...

Lijkt erop dat ze met het "fixen" van een beveiligingsprobleem eigenlijk de docker container wat om zeep hebben geholpen (of ja, warning).

Net even getest en bij een restart maakt de container hem weer 777 dus ja, dan zou je daar een task voor moeten opzetten ofzo

Ik zou het voor nu gewoon nog even negeren en niet zomaar de container updaten... Het is immers nog alleen maar een warning en ik zie er ook er github issues over.

[Gameboy]

Is er een specifieke reden waarom je dit per se als docker container wilt hebben?

De SynoCommunity heeft ook een native DSM package die je als Synology service kunt draaien:

https://synocommunity.com/package/mosquitto

[donald_dick]

PGID en GUID ingesteld als variabelen?

[zunrob]

Gameboy schreef op woensdag 6 december 2023 @ 15:55:
Is er een specifieke reden waarom je dit per se als docker container wilt hebben?

De SynoCommunity heeft ook een native DSM package die je als Synology service kunt draaien:

https://synocommunity.com/package/mosquitto

Niet per se een reden. Er draait wel meer in een Docker container, waaronder HA, dus dit leek me ook logisch. En werkte prima.

Het package kende ik nog niet!

[Septillion]

donald_dick schreef op woensdag 6 december 2023 @ 15:56:
PGID en GUID ingesteld als variabelen?

Dat pakt die stomme container dus ook al niet