svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

Adding Devin Teske to cc:

> On Mon, Apr 9, 2018 at 9:04 AM, Niclas Zeising
> <zeising+freebsd at daemonic.se> wrote:
> > On 04/02/18 17:39, Rodney W. Grimes wrote:
> >>>
> >>> Author: kevans
> >>> Date: Mon Apr  2 15:28:48 2018
> >>> New Revision: 331880
> >>> URL: https://svnweb.freebsd.org/changeset/base/331880
> >>>
> >>> Log:
> >>>    MFC r328331: Support configuring arbitrary limits(1) for any rc.conf
> >>> daemon
> >>>       Usage is ${name}_limits, and the argument is any flags accepted by
> >>>    limits(1), such as `-n 100' (e.g. only allow 100 open files).
> >>>
> >>> Modified:
> >>>    stable/11/etc/rc.subr
> >>> Directory Properties:
> >>>    stable/11/   (props changed)
> >>>
> >>> Modified: stable/11/etc/rc.subr
> >>>
> >>> ==============================================================================
> >>> --- stable/11/etc/rc.subr       Mon Apr  2 15:07:41 2018        (r331879)
> >>> +++ stable/11/etc/rc.subr       Mon Apr  2 15:28:48 2018        (r331880)
> >>> @@ -773,6 +773,8 @@ check_startmsgs()
> >>>   #
> >>>   #     ${name}_login_class n   Login class to use, else "daemon".
> >>>   #
> >>> +#      ${name}_limits  n       limits(1) to apply to ${command}.
> >>> +#
> >>
> >>
> >> Caution, limits(1) is in /usr/bin, this code can fail if used before
> >> /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
> >> this change if a call is made to limits.
> >>
> >>
> >
> > Sorry for jumping on this so late.  This is also an issue in CURRENT, and
> > has been since at least 2016.
> >
> > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291
> >
> 
> I kind of like Cy's approach in Comment #7.. scripts that start pretty
> early, at least, are bound to trip over all kinds of issues.

I think you mean comment #5, with a specific patch to rc.d/ddb in #7?
If so I like that approach.

> I don't think it's a good idea to work around this in rc.subr like his
> "relief valve" patch since it'll just create hidden inconsistencies in
> some of these things. _limits isn't getting applied, but it's not
> obvious that _limits isn't getting applied because we just silently
> work around it. Before we know it, we'll be adding something else
> that's nice in the general case but not applicable for some of these
> earlier bits.

Agree fully with that, changing behavior based on avaliablility of
a critical function would be a POLA issue.

> Rod, what are you thoughts on these approaches?

I am ok with Cy's #5/#7 fix.  I would like to look closer at this
limits(1) issue, as I do not understand why /etc/rc* suddenly grew
the need to start tossing limits on programs in a generic way.

Also if a specific user has a specific need to put a limit on a
program could that not be done with:

	program_foo_limits="-C blah blah"
	foo_program="limits ${program_foo_limits} foo"

in /etc/rc.conf or where ever else it is valid to do this.

I would also like to ask Devin Teske to weigh in on these issues,
so have added them to the CC: of this reply.


-- 
Rod Grimes                                                 rgrimes at freebsd.org