Emails naar PDF converteren

[Gerco]

Ik moet voor mijn werk nogal wat emails naar PDF converteren (voornamelijk bonnetjes van hotels, vliegtickets, etc). Aangezien ik er een beetje moe van wordt om steeds maar weer de mail naar PDF te "printen", in een map te plaatsen en uploaden naar de expense reporting applicatie zoek ik een betere oplossing.

Die heb ik deels gevonden in procmail. Ik maak een alias aan op mijn domain en laat procmail een script draaien wat de binnenkomende email naar PDF converteert en daarna upload naar Dropbox. Voor converteren naar PDF gebruik ik eerst MhonArc om de email naar HTML om te zetten en daarna naar PDF met wkhtmltopdf.

Aangezien vooral wkhtmltopdf met een gigantische berg dependencies komt bedacht ik me dat ik dat beter in een Docker container kon gieten om het nog een beetje behappelijk te houden. De oplossing is dus geworden:

email-to-pdf (een docker container die een bestand naar PDF converteert, Github), Dropbox-Uploader en het volgende shell script:

Bash:

#!/bin/bash

set -e

UUID=`uuidgen`

# Write the email to a temporary file
cat > $HOME/tmp/$UUID.eml
chmod 644 $HOME/tmp/$UUID.eml

# Convert to PDF
docker run --rm -v $HOME/tmp:/vol gerco/email-to-pdf $UUID.eml > $HOME/pdf/$UUID.pdf

# Upload file
DIRNAME=`date "+%Y-%m-%d"`
$HOME/dropbox_uploader.sh upload $HOME/pdf/$UUID.pdf /$DIRNAME/

# Remove temporary files
rm $HOME/tmp/$UUID.eml
rm $HOME/pdf/$UUID.pdf

Dit werkt op zich allemaal prima, maar ik zit nog met 1 probleem: beveiliging. Om dit alles werkend te krijgen moet de user waaronder het procmail shell script draait toegang krijgen tot de Docker daemon. Dat is natuurlijk makkelijk te doen door gewoon die user in de docker groep te gooien, maar dan krijgt 'ie zo ongeveer direct root toegang en dat lijkt me wat onwenselijk.

Op zich is het beveiligingsprobleem nog redelijk beperkt omdat:
[ul]
• Er gaat geen input van het netwerk direct naar de Docker daemon
• Het proces wat de email omzet binnenin de container draait als "nobody", heeft dus nergens schrijfrechten en kan ook niet als root met de kernel kan praten.
• Het shell script is niet schrijfbaar door de user waaronder procmail draait dus het "docker run" command kan niet gewijzigd worden.


Heeft er iemand een idee over hoe ik die docker container kan draaien zonder de user die hem uitvoert direct root te maken of anders nog andere maatregelen anders dan bovenstaande die ik kan toevoegen om de beveiliging te verbeteren?

[ Voor 14% gewijzigd door Gerco op 24-11-2015 02:12 ]

[BoAC]

Kun je het script niet laten draaien onder de betreffende gebruiker met het setuid bitje: http://unix.stackexchange...w-setuid-on-shell-scripts

Gokje naar de goede richting?

[Gerco]

BoAC schreef op dinsdag 24 november 2015 @ 07:10:
Kun je het script niet laten draaien onder de betreffende gebruiker met het setuid bitje: http://unix.stackexchange...w-setuid-on-shell-scripts

Gokje naar de goede richting?

setuid op een bash script is niet zo'n goed idee volgens die link. Er staat echter ook dat Perl expliciet *wel* setuid ondersteunt op Perl scripts dus dat kan ik waarschijnlijk wel gebruiken.

[edit]
Perl ondersteunt het ook niet meer zo te zien. Misschien is een regeltje opnemen in sudoers dan wel de beste oplossing.

[edit2]
Onderstaande toegevoegd in sudoers en het werkt prima. Mijn user hoeft niet meer in de docker group te zitten en kan toch dit ene command uitvoeren.

code:

User_Alias      RECEIPTS_USER = user1, user2, whatever
Defaults:RECEIPTS_USER !requiretty
RECEIPTS_USER   ALL=(:docker) NOPASSWD: /usr/bin/docker run --rm -v /full/path/to/tmp/directory\:/vol gerco/email-to-pdf *

Docker regeltje in shell script aangepast naar:

Bash:

sudo -g docker /usr/bin/docker run --rm -v $HOME/tmp:/vol gerco/email-to-pdf $UUID.eml > $HOME/pdf/$UUID.pdf

[ Voor 42% gewijzigd door Gerco op 25-11-2015 00:54 ]

[daft_dutch]

omdat het toch over veiligheid gaat. zie het niet expliciet staan.
die user kan dat sudo granted script toch niet bewerken? Ander schiet je niets op

[The Eagle]

Waarom moet het uberhaupt PDF zijn? Is een foto niet goed genoeg

[RemcoDelft]

Gerco schreef op dinsdag 24 november 2015 @ 01:21:
Ik moet voor mijn werk nogal wat emails naar PDF converteren (voornamelijk bonnetjes van hotels, vliegtickets, etc).

Omdat je emails zegt, ga ik er vanuit dat het uit een scanner komt... Heeft die niet heel toevallig de optie om naar PDF te scannen? Zo doen we dat hier

[Gerco]

daft_dutch schreef op zaterdag 28 november 2015 @ 17:16:
die user kan dat sudo granted script toch niet bewerken? Ander schiet je niets op

Die user kan dat script inderdaad niet bewerken. Zelfs als dat wel kon kun je het command dat sudo toelaat niet aanpassen. Sudo laat alleen dat specifieke "docker run" command toe, het enige wat mag varieren is de filename op het eind.

The Eagle schreef op zaterdag 28 november 2015 @ 17:22:
Waarom moet het uberhaupt PDF zijn? Is een foto niet goed genoeg

RemcoDelft schreef op zaterdag 28 november 2015 @ 17:25:
Omdat je emails zegt, ga ik er vanuit dat het uit een scanner komt... Heeft die niet heel toevallig de optie om naar PDF te scannen? Zo doen we dat hier

Foto of scan mag ook, maar in dit geval gaat het om aankoopbewijzen die via email komen (vliegtickets, hotel reserveringen, huurauto's, Uber bonnetjes, etc.), die heb ik natuurlijk alleen als email. Het gaat erom dat ik het naar PDF kan omzetten zonder computer, printer of scanner bij de hand te hebben. Nu kan ik de mail gewoon van mijn telefoon forwarden en er staat 10s later een PDF in mijn dropbox voor wanneer ik die moet uploaden naar het expenses systeem.

[ Voor 51% gewijzigd door Gerco op 28-11-2015 19:16 ]

[daft_dutch]

klinkt praktisch

[Thc_Nbl]

leuke oplossing, wij (op kantoor) gebruiken wel wkhtmltopdf op kantoor met een headless X- oplossing.

Vraagje.. als er bijlages in de e-mail zitten, hoe gaat deze daar mee om, zie je de bijlage ook in het eindrestulaat?
bij ons is het gewoon en perl script waar ik naartoe email, genereren naar pdf en de email terug ontvangen duurt nu ongeveer 5 sec.
vroeg me af hoe dat met docker gaat, ik ben zelf nog niet bekend met docker.

[Gerco]

Thc_Nbl schreef op zondag 29 november 2015 @ 17:29:
Vraagje.. als er bijlages in de e-mail zitten, hoe gaat deze daar mee om, zie je de bijlage ook in het eindrestulaat?

Nog niet. MhonArc doet weinig interessants met bijlages. Slaat ze op in een apart bestand en stopt een link in de HTML. Die HTML gaat vervolgens door wkhtmltopdf die er niets bijzonders mee doet. In mijn oplossing kun je nog wel zien dat er een bijlage was, maar de inhoud is kwijt. Daar wil ik nog wel iets mee doen, maar heb ik nog geen tijd voor gehad.

Uiteindelijk wil ik meerdere emails kunnen forwarden als attachment (1 email met meerdere .eml attachments dus) en dan allemaal als aparte PDF op dropbox zetten. Images moeten inlined worden (cid: urls werken al wel) en de rest maakt me niets uit.

bij ons is het gewoon en perl script waar ik naartoe email, genereren naar pdf en de email terug ontvangen duurt nu ongeveer 5 sec. vroeg me af hoe dat met docker gaat, ik ben zelf nog niet bekend met docker.

Docker voegt een fractie van een seconde aan overhead toe, het is niet merkbaar. Wachten op de Dropbox client om naar mijn laptop te syncen duurt vele malen langer dan de conversie->upload procedure. Alles bij elkaar is het binnen 20s gebeurd, maar de conversie duurt maar enkele seconden.

[Thc_Nbl]

okdan, dat is bijna hetzelfde als wij bij ons doen. die inhoud raken wij niet kwijt, daar heeft mijn college wat op gevonden, via de headless x de bijlage printen en zo converteren we bv ook gelijk word en excel files naar pdf, ook iets wat mijn college opgezet heeft.
voor die eml op Linux is niet veel, hij heeft een functie uit een programma genomen en die aangepast, bij ons wordt het bijna allemaal naar pdf ongezet om zo op een webserver klaar te zetten voor de web apps.
en alles werkt eigenlijk door naar een email adres te mailen.

dat docker lijkt bij ook wel interessant, daar ga ik mij ook maar eens in verdiepen.
bedankt voor de info.

[johnkeates]

Waarom zit docker er bij?

[Gerco]

johnkeates schreef op vrijdag 04 december 2015 @ 00:20:
Waarom zit docker er bij?

Voornamelijk omdat de server waar ik dit op draai een shared server is. Er staat van alles en nog wat op, maar geen X-Windows. Om problemen met dependencies te voorkomen en om de server niet vol te stampen met duizenden libraries die alleen voor dit specifieke appje nodig zijn (en dus voor de rest van de server alleen maar attack surface toevoegen) besloot ik om het in Docker te gieten. Een chroot-jail had waarschijnlijk net zo goed gewerkt, maar ik had geen zin om dat uit te zoeken.

Dus: voornamelijk voor deployment en UNdeployment gemak en een beetje voor beveiliging.