Hi, Simon,
Simon Richter writes:
> For systemd, resource limits should not be set by pam_limits, because
> pam_limits reads /etc/security/limits.conf, while the systemd ecosystem
> stores resource limits in the unit files.
Please read [1].
[1]:
Hi Ansgar,
On Mon, Feb 01, 2021 at 09:50:40PM +0100, Ansgar wrote:
> 1. Resources limits set for a system service (e.g. sshd) might not be
>appropriate for a user session opened by the system service.
>Debian's PAM patch seems to be targeted at dealing with this by
>defaulting to
Hi Simon,
I think there are three aspects in your mail: the behavior of
pam_limits, defaults for resource limits on legacy init systems and some
discussion of sysvinit scripts that seems unrelated:
1. Resources limits set for a system service (e.g. sshd) might not be
appropriate for a user
On Mon, 01 Feb 2021 at 11:16:48 -0800, Russ Allbery wrote:
> pam_limits also does some things that are unrelated to starting services,
> such as setting up limits for interactive user sessions, and I think pure
> systemd systems still rely on that?
My understanding was that pam_limits is *only*
Simon Richter writes:
> Absolutely. The vast majority of users has no need for encrypted swap,
> but might reasonably assume that secret keys are not written unencrypted
> to disk, especially not in a way that is likely to leave them there for
> weeks.
That is not a reasonable assumption. If
Simon Richter writes:
> On Mon, Feb 01, 2021 at 12:30:30PM -0500, Sam Hartman wrote:
>
>> It sounded like you were proposing that pam detect if systemd was pid1
>> and if so, then do what it does today otherwise inherit limits by
>> default.
>
> PAM itself doesn't need to detect anything, the
Simon Richter writes:
> The way I see it, we want a pam_systemd module that is responsible for
> applying *all* settings configured in systemd units, and that is kept in
> sync with the unit file parser, and the pam_limits module to handle the
> non-systemd setups.
My understanding is that if
Simon McVittie writes:
> On Mon, 01 Feb 2021 at 09:54:56 -0800, Russ Allbery wrote:
>> Does this serve any useful purpose?
> Honestly, probably not, but removing security hardening (however
> dubious) is a regression, and if I remove it I'm sure there'll be a CVE
> ID on the way shortly.
I
Hi Russ,
On Mon, Feb 01, 2021 at 09:54:56AM -0800, Russ Allbery wrote:
[keyring managers using mlock]
> Does this serve any useful purpose?
Absolutely. The vast majority of users has no need for encrypted swap, but
might reasonably assume that secret keys are not written unencrypted to
disk,
Hi Sam,
On Mon, Feb 01, 2021 at 12:30:30PM -0500, Sam Hartman wrote:
> It sounded like you were proposing that pam detect if systemd was pid1
> and if so, then do what it does today otherwise inherit limits by
> default.
PAM itself doesn't need to detect anything, the individual modules are
On Mon, 01 Feb 2021 at 09:54:56 -0800, Russ Allbery wrote:
> Simon McVittie writes:
> > The wider context here is that gnome-keyring-daemon, GNOME's
> > implementation of the org.freedesktop.Secrets interface, is currently
> > setcap cap_ipc_lock=ep so that it can mlock(2) secrets and stop them
>
Simon McVittie writes:
> The reason I ask about this is that I want to make sure we are setting
> rlimits, and in particular RLIMIT_MEMLOCK, to a realistic value for
> 2021. The wider context here is that gnome-keyring-daemon, GNOME's
> implementation of the org.freedesktop.Secrets interface,
> "Simon" == Simon McVittie writes:
Simon> On Mon, 01 Feb 2021 at 11:49:25 -0500, Sam Hartman wrote:
>> > "Simon" == Simon McVittie writes: I'm
>> assuming that the proposal is to change this for bookworm.
Simon> I'm sorry, I don't have a concrete proposal, and I don't
On Mon, 01 Feb 2021 at 11:49:25 -0500, Sam Hartman wrote:
> > "Simon" == Simon McVittie writes:
> I'm assuming that the proposal is to change this for bookworm.
I'm sorry, I don't have a concrete proposal, and I don't understand which
package is meant to be responsible for this well enough
> "Simon" == Simon McVittie writes:
I'm assuming that the proposal is to change this for bookworm.
It seems like it's too late in the process to change something like this
for bullseye without more explicit and significant harm documented than
you have given so far.
Simon> Rationale:
On Mon, 01 Feb 2021 at 13:58:57 +, Simon McVittie wrote:
> Rationale: on sysvinit or runit systems, pid 1 is very simple and is
> unlikely to need to elevate any limits, but sysadmins are expected
> to restart system services in an unpredictable execution environment
> (certainly true for
A recent regression in gnome-keyring (perhaps only on systems that
use dbus-x11, it isn't completely clear to me yet) has prompted me to
look at how rlimits work in Debian. It isn't clear to me which package
is or should be responsible for choosing what arbitrary limits we use
in practice.
The
17 matches
Mail list logo
