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 ses
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* fo
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 yo
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 indiv
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 yo
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 woul
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, es
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
resp
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, is
> "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 to
> "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
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 syste
Package: wnpp
Severity: wishlist
Owner: deb...@thola.io
* Package name: golang-github-inexio-go-monitoringplugin
Version : 0.0~git20201117.ec06ef4-1
Upstream Author : inexio
* URL : https://github.com/inexio/go-monitoringplugin
* License : BSD-2-clause
Program
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 ker
Hi,
this is the call for the nect video conference of the Debian Med team
that are an established means to continue the COVID-19 hackathon in
April[1] and we do it twice per month on every
2th and 17th
of a month. So the next meeting is tomorrow 18:00 UTC
For those who would like to join
17 matches
Mail list logo
