kan file permissions niet wijzigen

[leecher]

Ik draai een mosquitto server op ubuntu op mijn eigen netwerk en dat werkt al een paar jaar prima. Ik gebruik binnen het eigen netwerk een username+pw om te verbinden de met de mqtt server.

Ik wil ook mqtt berichten van buiten mijn netwerk gaan versturen naar deze server en dan is het wel mooi als gebeurt in combinatie met SSL. Ik heb een certificaat gegenereerd met behulp van certbot en deze bestanden staan in /etc/letsencrypt/live/domein/xxxx.pem.

In /etc/mosquitto/conf.d heb ik de volgende regels toegevoegd:

listener 8883
certfile /etc/letsencrypt/live/domein/cert.pem
cafile /etc/letsencrypt/live/domein/chain.pem
keyfile /etc/letsencrypt/live/domein/privkey.pem

Maar helaas: De MQTT server wil nu niet meer starten. Reden: Geen toegang tot deze .pem bestanden. Dat verbaasde me op zich niks omdat ik nog niks aan permissions had veranderd. Ik dacht een user group aan te maken (mqttcertuser), hier root en mosquitto aan toe te voegen en dan bij de mqttcertuser group leesrechten aan te maken.

voor de complete map /live/domein werkt dat, het lukt me echter niet om permissions van de .pem bestanden zelf te wijzigen. Ik krijg geen foutmelding als ik chmod gebruik maar tegelijkertijd verandert er niks. De .pem bestanden hebben nu 0777 permissions en het lukt me dus niet om dit aan te passen. Het veranderen van de owner is wel goed gegaan want die staat geregistreerd als root:mqttcertuser.

Hoe krijg ik dit aan de praat? Misschien klopt deze benadering in beginsel al niet?

[Hero of Time]

Bestanden horen hoe dan ook geen wereld rechten te hebben om alles te mogen. Zeker iets als uitvoerrechten is behalve bij binaries en scripts onnodig. In het ruimste geval voor dit soort zaken met certificaten is 644 het hoogste wat je geeft. Normaal gesproken zelfs 640, 'other' hoeft niet te lezen, alleen de gebruiker en groep. Jij hebt al een groep gemaakt en daar de juiste gebruiker aan toegevoegd. Root hoef je eigenlijk nooit aan groepen toe te voegen, het mag hoe dan ook alles, zelfs als deze niet aan een specifieke groep is toegevoegd.

Let op de paden zelf, die moeten volledig doorgaanbaar zijn voor de betreffende gebruiker en groep. Als een map van root:root is en 700 of 750 rechten heeft (mappen moeten wel uitvoerrechten hebben, anders mag je er niet in), dan maakt het niet uit of een onderliggende map of bestand bredere rechten heeft. Beetje als dat je wel aan tafel mag zitten, maar niet door de deur naar de ruimte mag waar die tafel staat.

Private keys wil je zo min mogelijk rechten op hebben, want die zijn, zoals de naam al zegt, private en de wereld hoeft daar echt niet bij. Alleen wel de gebruiker waaronder de service draait om de beveiligde communicatie te kunnen opzetten.

Hopelijk is het duidelijk genoeg voor je.

[leecher]

Ja dat 777 not done is weet ik, dat het hele pad die permissions moet hebben wist ik niet. De permissions van de mappen zelf aanpassen gaat wel, maar het vreemde is dat ik die 777 van de bestanden zelf niet krijg gewijzigd. Ik kan een chmod command uitvoeren maar die 777 blijft gewoon gehandhaafd. Ik krijg geen feedback dat er iets mis gaat. Het lijkt in steen gebeiteld en ik weet dus niet waarom. De permissions van de bestanden zelf wijzigen is denk ik de laatste horde, maar hoe krijg ik dat voor elkaar?

[davegriffejoen]

Voor zover ik weet zijn die 'bestanden' waar je naar verwijst symlinks naar de daadwerkelijke bestanden. Dus als je persissions wilt wijzigen moet je het van de echte bestanden doen.

[leecher]

Dan kan ik me voorstellen dat permissions instellen niet werkt. Als ik echter kijk in /letsencrypt/archive/domein (als dat de juiste plek is tenminste) dan staat de laatste versie op 640. In /live/domein staan ze nog op 777. Wat mis ik hier nog?

[aawe mwan]

Wat je mist is dat een symbolic link zelf geen rechten heeft (die lijken 777 te zijn).

Zo heb ik een symbolic link naar auth.log gemaakt en dat bestand mag ik lezen omdat ik lid ben van de groep adm, niet omdat ik zelf die symbolic link ooit gemaakt heb:

$ ll auth.log 
lrwxrwxrwx 1 mijn-user mijn-group 17 apr 28  2018 auth.log -> /var/log/auth.log

$ ll /var/log/auth.log
-rw-r----- 1 syslog adm 34859 sep  3 20:03 /var/log/auth.log