Question Mail() in chrooted environment

[cool_sh]

Hi there,

i was wondering if anyone of you has sendmail configured to use it in an chrooted environment and has instructions for it?

CentOS 7.3 / Onyx 17.5.3 #4

Best regards

 

[Bitpalast]

I think that this cannot be done, because sendmail is not just a program that is run standalone, but a daemon. On a server, this needs to control port 25, so there can only be one sendmail (or other smtp service). If you allow a subscription to access the daemon, the daemon could be controlled by that subscription e.g. stopped, restarted, reconfigured etc., which in turn could badly affect other subscriptions (they'd become dependent on the mercy of the one subscription owner who can access sendmail). It is not possible to have a second, alternative instance of sendmail in the chrooted environment, because this would conflict with the port 25 requirement. The only thing you could maybe do is to have another smtp service run on a different port, but what sense would this make? However, of course you can use the daemon's service from the chrooted environment (meaning you can use port 25 to send mail through it).

 

[cool_sh]

Hm,

the problem is that using "mail -s" in a chrooted environment is not working:

/usr/sbin/sendmail: No such file or directory
"//dead.letter" 9/247
. . . message not sent.

 

[tgmedia]

Have you guys found a solution?

If you have mail services enabled for this domain you can use smtp authentication perhaps, however, in my situation we can not enable mail service for that domain as it's hosted externally (and you don't want that mail getting delivered locally!).

Any more ideas?

 

[SpAcEDeViL]

i have the same situation...

i cannot give the user normal bash rights... they can see the hole system, include another domains and can read all files... thats a fatal security break...
Or how can i "chroot" a normal bash user to there own homedir and have no access to another files?

 

[tgmedia]

@IgorG any ideas?

 

[UFHH01]

Hi @ all ,

I think this KB - article should help you to solve your issue:

=> How to allow user with enabled chrooted shell run scheduled tasks outside chrooted environment​