has a ticket been opened for this ? we will fix but i'd like to have some tracking
On Thu, Mar 06, 2014 at 10:36:46AM +0100, Michael Neumann wrote: > > > Am 05.03.2014 17:26, schrieb Gilles Chehade: > > On Wed, Mar 05, 2014 at 06:36:06PM +0530, Ashish SHUKLA wrote: > >> On Wed, 05 Mar 2014 13:56:06 +0100, Michael Neumann > <[email protected]> said: > >> > >>> Am 05.03.2014 13:41, schrieb Ashish SHUKLA: > >>>> On Wed, 05 Mar 2014 13:25:34 +0100, Michael Neumann > >>> <[email protected]> said: > >>>>> Hi, > >>>> > >>>>> I am having problems to let OpenSMTPD directly talk with > dovecot via an > >>>>> LMTP UNIX domain socket. > >>>> > >>>>> The domain socket is created with _smtpd:_smtpd 0660 permissions: > >>>> > >>>>> # ls -la /var/run/dovecot/lmtp > >>>>> srw-rw---- 1 _smtpd _smtpd 0 Mar 4 12:06 /var/run/dovecot/lmtp > >>>> > >>>>> But somehow the smtpd process can't access it. It shows a "smtpd: > >>>>> couldn't establish connection: Permission denied" in the output of > >>>>> `smtpctl show queue`. It is working if I give it read/write > permissions > >>>>> for everyone (0666). > >>>> > >>>>> Which permissions should it have? I also tried to give it > _smtpq:_smtpd > >>>>> permissions (or root:wheel), but both failed. I am a bit lost here > >>>>> because I don't know which process opens the socket. Can someone > >>>>> enlighten me? :) > >>>> > >>>> That's because LMTP delivery (like all delivery backends) work by > >>> setuid-ing > >>>> to the recipient user so the actual delivery takes place in the > >>> context of > >>>> recipient user. So, 666 seems like a workaround, or switch to > >>> delivery over > >>>> TCP/IP. > >> > >>> Thanks! > >> > > > > Well, we most definitely want to drop privileges but maybe we should > > make it possible (again) to drop privileges to a specific user when > > a mda is executed: > > > > accept [...] deliver to mda [...] as _dovecot > > > > we had this working at some point and it got removed because we had > > no use-case for it ... but this seems like a valid use-case. > > Well, I consider this very useful in combination with virtual users, > where the users we deliver to do not exist as system users. > > Regards, > > Michael > > -- > You received this mail because you are subscribed to [email protected] > To unsubscribe, send a mail to: [email protected] > -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
