Cloudron Forum

Upvoting as well

@jdaviescoates thank you - I've got mail restored using backup, which required a few hours, but the data is there.

But I can't really can't see any reason keeping it enabled by default. How many modern mail clients can't handle search across all folders?

I understand that you can't satisfy everyone with changes - just wanted to let you know that I'm on the side that is shall not be a default; unless I'm missing something, people lived happily up till 7.5.1

@joseph said in Virtual "all mail" folder after 7.5.1 update:

It should be in the Email -> Settings

Thank you! It is!

I second a vote to have this option disabled by default, please!

I just managed to wipe all my e-mail, trying to get rid of it... =(

@girish said in Virtual "all mail" folder after 7.5.1 update:

@estudios507 we will add an option to disable it in next release.

Is there any updates on that? I thought it's some of my e-mail clients makes mess around my folders, see now that it's not and found that thread.

How do I hide / remove that folder / view at the latest Cloudron?

For anyone wondering on the same question as I did: Dovecot seems to be a standard IMAP server for now, which seems to be used on majority of servers. It claims to be written with security in mind, which doesn't seem to help to avoid privileges escalations, buffer overflow, crashes (on the same page - below).

Given the dominance of that mail server on the internet, it seems to be a go-to solution for many, just like Ubuntu, referred here above, is; so I wouldn't expect it to be replaced on Cloudron anytime soon.

Given the self-confidence of the authors, that claims that running from root is not a big deal and not providing any easily ready to use solution, I doubt that many will go extra mile to implement that on they own; given Cloudron limited resources and luck of advertising and hence focus to be security first platform, dovecot processes will remain to be running as root.

From the positive side, root owned processes are not opening any network port, so direct exploitation would be problematic.

Hope that would be of help.

Guess it is impossible - that makes sense, though to ask, just in case. Thank you!

SSE-C requires TLS - which means minio has to be running on 443 port directly.

It seems, like there is no other way around.

Is it something that could happen on Cloudron?

@nebulon said in Why running dovecot as root?:

@necrevistonnezr this may be more of a case of slightly different priorities and taste, servers running software (and exposed to the internet) are never 100% secure, so hardening is always a bit of an ongoing process which can be as detailed as one wants. We try to strike some balance on Cloudron side, to keep things maintainable and updatable also.

Thanks again - that makes perfect sense.
If I may ask - did you consider other alternatives? If so - what did you rejected and why? Would you choose Dovecot again now?

Feel free to ignore my questions - that's definitely outside of the scope of the platform, would appreciate if you could share some piece of wisdom thought!

@necrevistonnezr said in Why running dovecot as root?:

But anyway, this is tiring. Checking out.

Can't recall I've been begging you to join and participate in the discussion... In case if I did, sure - don't hesitate to explore things around - it's so much better without some kind of knowledge (and it's not a joke).

@necrevistonnezr , it seems like you miss the fact that Dovecot created instruction afterwards.
Another thing is that if the product of your choice doesn't support best or just good enough security practices - it might be worth to change the product.

@nebulon , got it, it's a pity. I would rather have all processes in Docker (including nginx) running as non-root.
But probably it's a subject for another project 'Hardened Cloudron', that doesn't seem to be in high demand, so from the product perspective I understand your choice - thanks for letting me know it!

The thing is that there is a guide to run dovecot not as root...

@necrevistonnezr it seems like I've covered every one of your points in my messages earlier - please, let me know if you feel like I missed something.

@necrevistonnezr yeah, I addressed that earlier:

There is something doesn't add up for me in they way of thinking. For me - a good security rule - it's to minimize attack surface, since you can never know. That is the approach of OpenBSD system, for example. Separate, minimize exposure, etc.

For me the quote you mentioned only speaks about self-posed mindset limit.

It's like saying that you don't need airbags on the car, as usually people doesn't get in the car crash, and if they would - a seatbelt would be sufficient.

another issue: mail server doesn't re-register itself on the new IP

apart from everything, I had one app missing in my backup - luckily it was a migagration, not a disaster recovery; from time to time I still have issues with backups not being cleaned up, leading to unexpected costs from the storage provider...

2024-10-19T13:49:04.789Z box:dns registerLocation: Get error. retryable: true. Invalid request IP: xxx.xxx.xxx.xxx
2024-10-19T13:49:04.794Z box:provision restoreTask: error. BoxError: Invalid request IP: xxx.xxx.xxx.xxx at registerLocation (/home/yellowtent/box/src/dns.js:237:15) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async /home/yellowtent/box/src/dns.js:276:17 at async promiseRetry (/home/yellowtent/box/src/promise-retry.js:17:20) at async Object.registerLocations (/home/yellowtent/box/src/dns.js:266:9) at async restoreTask (/home/yellowtent/box/src/provision.js:193:13) { reason: 'External Error', details: {} }

Caused me to recreate VM from scratch, re-verify / cleanup IP address, restart the whole recovery process.

Only because there was an error with DNS settings at Namecheap.

I've posted earlier troubleshooting with Hetzner's box encrypted files.

It's quite a disaster, to be honest...

in my specific case - that was due to decryption key error

Hetzner's box, SSHFS with encryption - recovery fails with:

2024-10-19T13:37:34.456Z box:provision setProgress: restore - Downloading backup /mnt/cloudronbackup/my_domain_cloudron/2024-10-19-130519-879/box_v8.0.6.tar.gz.enc
2024-10-19T13:37:34.456Z box:storage/filesystem download: /mnt/cloudronbackup/my_domain_cloudron/2024-10-19-130519-879/box_v8.0.6.tar.gz.enc
2024-10-19T13:37:34.547Z box:backupformat/tgz Attempt 2 failed. Will retry: tarExtract pipeline error: incorrect header check

Checking the file:

file /mnt/cloudronbackup/my_domain_cloudron/2024-10-19-130519-879/box_v8.0.6.tar.gz.enc
/mnt/cloudronbackup/my_domain_cloudron/2024-10-19-130519-879/box_v8.0.6.tar.gz.enc: data

Guess encrypted data can't have tar headers?

@girish from the link above I can see:

Dovecot can simply be started by running dovecot as root.

can != must for me.

There is something doesn't add up for me in they way of thinking. For me - a good security rule - it's to minimize attack surface, since you can never know. That is the approach of OpenBSD system, for example. Separate, minimize exposure, etc.

Dovecot has a guide on how to run in non-root: https://doc.dovecot.org/2.3/configuration_manual/howto/rootless/

At the begging they give very strange comment about a necessity to choose between chroot-ed and non-chroot-ed environment, while giving permissions to chroot without root in the section to follow.

Anyway - do you believe the manual from that link could be of any help?

Even on official Docker docs (for example) says:

Docker will run commands as the root user, which can pose significant security risks.

@nebulon , it might be not too much complicated, if branded name is exposed via some kind of API, like you expose Cloudron version (for some reason) now via /api/v1/cloudron/status.

You can then do fetch for that custom name using JS's fetch() and that's it.

btw, why would you expose platform version in the public accessible API?