|Summary:||rc.subr limits call breaks non-root usage|
|Product:||Base System||Reporter:||Markus Wild <freebsd-bugs>|
|Component:||conf||Assignee:||freebsd-rc mailing list <rc>|
|Severity:||Affects Some People||CC:||cem|
|Priority:||---||Keywords:||feature, needs-qa, regression|
Description Markus Wild 2019-01-22 09:46:10 UTC
We sometimes want customers to be able to restart services (like ldap) running on non-standard and non-privileged ports. With the new unconditional call to "limits" in the rc.subr start function, this fails: $ sh /usr/local/etc/rc.d/slapd start Starting slapd. limits: setrlimit datasize: Operation not permitted I suggest a change like the following: --- /etc/rc.subr.orig 2019-01-22 10:40:13.973245000 +0100 +++ /etc/rc.subr 2019-01-22 09:51:18.058288000 +0100 @@ -1073,7 +1073,9 @@ fi # Prepend default limits - _doit="$_cd limits -C $_login_class $_doit" + if [ `/usr/bin/id -u` -eq 0 ]; then + _doit="$_cd limits -C $_login_class $_doit" + fi # run the full command # and the same service can now be maintained by a non privileged user: $ sh /usr/local/etc/rc.d/slapd start Starting slapd. Kind regards, Markus
Comment 1 Kubilay Kocak 2019-01-22 09:53:55 UTC
Thank you for the report and patch Markus. Could you please include your patch as an attachment?
Comment 2 Markus Wild 2019-01-22 09:59:18 UTC
Created attachment 201326 [details] patch to allow non-root bypass of call to limits Here's the patch as attachment.
Comment 3 Conrad Meyer 2019-01-22 16:58:39 UTC
This change comes with the caveat that services started by non-privileged users will silently have different, non-default limits which may impact the function of the service.
Comment 4 Markus Wild 2019-01-23 08:15:41 UTC
(In reply to Conrad Meyer from comment #3) services started by non privileged users will inherit the limits of those users, which at least in my understanding is working as intended. An alternative approach would be to have a generic _limit_enable variable per service, in the same spirit as services such as apache used to have before there was central support for service limits. My approach was the one with the least amount of needed changes and potential impact to existing setups (considering that there was no central limits support previously).