FS#57721 - [gitlab] NoNewPrivileges=true in gitlab-unicorn.service conflicts with mail delivery with postfix
Attached to Project:
Community Packages
Opened by Jakub Klinkovský (lahwaacz) - Monday, 05 March 2018, 14:18 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Sunday, 01 April 2018, 19:04 GMT
Opened by Jakub Klinkovský (lahwaacz) - Monday, 05 March 2018, 14:18 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Sunday, 01 April 2018, 19:04 GMT
|
Details
The gitlab-unicorn.service contains NoNewPrivileges=true
which prevents correct mail delivery with postfix, because
/usr/bin/postdrop needs setgid. I got many of the following
log items in the journal (shown with -o verbose to see which
unit is responsible):
Fri 2018-03-02 21:06:16.989562 CET [...] _TRANSPORT=syslog _BOOT_ID=[...] _MACHINE_ID=[...] _HOSTNAME=[...] _SYSTEMD_SLICE=system.slice _UID=105 _GID=105 _CAP_EFFECTIVE=0 PRIORITY=4 SYSLOG_FACILITY=2 SYSLOG_IDENTIFIER=postfix/postdrop SYSLOG_PID=13353 MESSAGE=warning: mail_queue_enter: create file maildrop/989524.13353: Permission denied _PID=13353 _COMM=postdrop _EXE=/usr/bin/postdrop _CMDLINE=/usr/bin/postdrop -r _SYSTEMD_CGROUP=/system.slice/gitlab-unicorn.service _SYSTEMD_UNIT=gitlab-unicorn.service _SYSTEMD_INVOCATION_ID=[...] _SOURCE_REALTIME_TIMESTAMP=1520021176989562 The gitlab-sidekiq.service contains this comment [1] so I'm wondering if this is a bug or it is possible to configure gitlab to run all mail delivery in the gitlab-sidekiq service. # NoNewPrivileges breaks gitlabs' email delivery if you # use postfix' sendmail wrapper. If you use an SMTP server # instead you can safely enable this security feature. #NoNewPrivileges=true [1] https://git.archlinux.org/svntogit/community.git/tree/trunk/gitlab-sidekiq.service?h=packages/gitlab#n19 |
This task depends upon
Comment by
Sven-Hendrik Haase (Svenstaro) -
Friday, 16 March 2018, 04:04 GMT
Comment by
Jakub Klinkovský (lahwaacz) -
Friday, 16 March 2018, 18:08 GMT
Comment by
Jakub Klinkovský (lahwaacz) -
Thursday, 29 March 2018, 15:52 GMT
Comment by
Sven-Hendrik Haase (Svenstaro) -
Thursday, 29 March 2018, 16:37 GMT
Check out 10.5.5.
Thanks. You might want to close this task.
- Field changed: Percent Complete (100% → 0%)
It turns out that disabling NoNewPrivileges=true is not enough
because there is still CapabilityBoundingSet= which disables the
CAP_SETGID capability.
Alright, test the new package, please.