control: tags -1 confirmed >>>>> "Simon" == Simon McVittie <s...@debian.org> writes:
Simon> History =======
Simon> This appears to have been caused by a patch submitted in
Simon> 2000, originally to fix #63230
Simon> (d/patches-applied/027_pam_limits_better_init_allow_explicit_root).
Simon> Unfortunately, this combines several related changes into a
Simon> single patch, so inspecting its history isn't
Simon> straightforward.
Thanks for your detailed bug report.
I've tried to bring this all into my memory to actually get to a place
where I can make a decision.
Reviewing 027_pam_limits_better_init_allow_explicit_root, the patch does
the following things:
* group and all entries do not apply to root; you have to explicitly
set root limits. I think we want to keep this; it is documented
behavior on Ubuntu and Debian and seems reasonable.
* always acts as if set_all is set. I analyze this below and conclude we
do not want to keep.
* Provides better defaulting in the case that we're not running on linux
or in the case we cannot get kernel limits.I'm not really sure this is
worth keeping. I don't consider our current non-linux ports to be
worth a lot of effort, and it seems reasonable to say that if you are
going to use set_all you should make it possible for pam_limits to
read the limits. However, keeping that code is relatively easy to do.
My plan is to keep it until it becomes a problem.
Note that this patch also interacts with a later patch that caps the
soft limit of the number of files at 1024.
So, let's take a look at the cases where set_all is an issue.
## Services run by systemd
As you point out, using set_all by default makes it difficult to use
systemd's resource control facilities.
For this use case, Debian would be significantly improved by not
defaulting to set_all.
## Using privilege Gates on a Systemd System
I do think it would be good if su and other privilege gates would
consider using set_all.
However even without that, I think that most services are run by systemd
today, and that's definitely the best design pattern.
So I think that the impact of not resetting limits by default will be
significantly reduced over what we saw in 2000.
I think even if su and other privilege gates do not adopt set_all we
will net improve Debian by dropping the default to set_all.
I think the residual bug would likely to be of severity minor.
## pam_limits and Containers
Like systemd, container managers have resource control mechanisms to set
limits and default limits. These may not be as advanced as systemd in
all cases, but they do exist.
pam_limits defaulting to set_all negatively impacts these controls in
cases where a pam session is started.
## Alternative Init System Development
In Vote 2019-002 Debian expressed support for using Debian as a platform
to explore and develop alternate init systems beyond systemd. That
decision does not require a GR to reverse and may evolve over
time. Let's assume it is still in full effect.
It seems clear from the experience of systemd, upstart and container
managers that we want something between pid 1 and whatever starts
services to provide resource control facilities and to set limits.
However, people may be exploring other aspects of alternate init
systems and not focus on providing a resource control system.
So people doing this development work may not yet have a solution to
resource control better than sysvinit.
By default today's pam_limits will set limits similar to what the
kernel establishes.
The only case where that will not happen is if pam_limits or some other
facility sets limits on a process. By not defaulting to set_all, then
and pam_limits in such a process would require explicit configuration to
change those limits.
I think that's entirely reasonable behavior.
## My plans:
* do not default to set_all for this patch.
## Future work
I think it wouldbe be desirable to see if there's some other pid besides
pid 1 we could use for looking at default limits. At least on systemd
systems, pid 1 is a singularly bad choice for looking at limits. I
wonder if looking at pid 2 if it exists might be a better choice.
signature.asc
Description: PGP signature
