Bug#982436: procps: Please allow overriding protect-links.conf settings via /etc/sysctl.conf

2022-01-14 Thread intrigeri
Hi,

Since then, a duplicate bug report was filed (#1000908) and promptly
fixed in 2:3.3.17-6 ⇒ this bug report can now be closed :)

Cheers!



Bug#982436: procps: Please allow overriding protect-links.conf settings via /etc/sysctl.conf

2021-02-19 Thread Craig Small
On Fri, 19 Feb 2021 at 19:21, intrigeri  wrote:

> I confirm this problem does not happen when I use "sysctl --system".
> However, this problem does happen with procps 2:3.3.17-4 after
> a reboot (or more simply, after restarting procps.service).
>
I'm really not sure why this would matter after 3.3.17-4 as 3.3.16-1 is
where the file moved from /etc to /usr/lib but its been protect-links.conf
for a while.


> My understanding is that when using systemd, what matters is what
> systemd-sysctl does, not what "sysctl --system" does: procps.service
>
Right, you're talking about what the systemd-sysctl does, not the procps
sysctl. However the protect-links.conf is in the procps package, hence the
bug report is here.

So, ignoring the version bit (its the same file) and knowing its the
systemd binary makes this a lot clearer.

I'll have to look into what happens with changing the name of this file.
It's not strictly speaking a conffile but if someone had put a
/etc/sysctl.d/protect-links.conf its not going to match anymore.
It might be just a matter of putting something into the NEWS as for most
people nothing will change.  If you (or someone else reading this) has some
precedent where a sysctl file in /usr/lib is renamed then I'm happy to hear
about it.

 - Craig


Bug#982436: procps: Please allow overriding protect-links.conf settings via /etc/sysctl.conf

2021-02-19 Thread intrigeri
Hi Craig,

Craig Small (2021-02-15):
>   Are you sure you are still seeing this in 3.3.17? The directory orders
> got changed around in that release so it might be fixed already.
>
>  $ strace sysctl --system 2>&1 | egrep 'openat.*(etc|lib)/sys'
> [...]
>
> /etc/sysctl.conf is read after /usr/lib/sysctl.d/protect-links.conf
> That's what you wanted right?
>
> [...]
>
> root@floyd:~# /sbin/sysctl --system
> [...]
> ** Applying /usr/lib/sysctl.d/protect-links.conf *...
> *fs.protected_fifos = 1*
> fs.protected_hardlinks = 1
> fs.protected_regular = 2
> fs.protected_symlinks = 1
> * *Applying /etc/sysctl.conf* ...
> net.ipv6.conf.all.accept_redirects = 0
> net.ipv6.conf.default.accept_redirects = 0
> *fs.protected_fifos = 2*
>
> root@floyd:~# sysctl fs.protected_fifos
> f*s.protected_fifos = 2*

I confirm this problem does not happen when I use "sysctl --system".
However, this problem does happen with procps 2:3.3.17-4 after
a reboot (or more simply, after restarting procps.service).

My understanding is that when using systemd, what matters is what
systemd-sysctl does, not what "sysctl --system" does: procps.service
is a symlink to systemd-sysctl.service, which calls systemd-sysctl and
not "sysctl --service". So, in order to solve this bug on Debian
systems that use systemd, one needs to do either one of:

 a) Modify the behavior of systemd-sysctl so it matches the current
behavior of "sysctl --system". I don't know how realistic this is.

 b) Rename protect-links.conf as I suggested, so it integrates more
nicely with the configuration system it's de facto primarily meant
for nowadays.

Does this make sense?
Sorry if I totally misunderstood or missed something!

Cheers,
-- 
intrigeri



Bug#982436: procps: Please allow overriding protect-links.conf settings via /etc/sysctl.conf

2021-02-15 Thread Craig Small
On Wed, 10 Feb 2021 at 21:09,  wrote:

> I have set fs.protected_fifos=2 in /etc/sysctl.conf.
> My intent is to override procps' protect-links.conf,
> which sets fs.protected_fifos=1.
>
> Under systemd, /etc/sysctl.conf is actually loaded via the
> /etc/sysctl.d/99-sysctl.conf symlink, which sorts before
> protect-links.conf, so the distro setting from protect-links.conf
> overrides the custom value I've set in /etc/sysctl.conf.
>

Hi,
  Are you sure you are still seeing this in 3.3.17? The directory orders
got changed around in that release so it might be fixed already.

 $ strace sysctl --system 2>&1 | egrep 'openat.*(etc|lib)/sys'
openat(AT_FDCWD, "/etc/sysctl.d",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/local/lib/sysctl.d",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/usr/lib/sysctl.d",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/lib/sysctl.d",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/lib/sysctl.d/10-test1.conf", O_RDONLY) = 3
openat(AT_FDCWD, "/usr/lib/sysctl.d/30-tracker.conf", O_RDONLY) = 3
openat(AT_FDCWD, "/usr/lib/sysctl.d/50-bubblewrap.conf", O_RDONLY) = 3
openat(AT_FDCWD, "/usr/lib/sysctl.d/50-pid-max.conf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/sysctl.d/99-sysctl.conf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/sysctl.d/999-test1.conf", O_RDONLY) = 3
openat(AT_FDCWD, "*/usr/lib/sysctl.d/protect-links.conf*", O_RDONLY) = 3
openat(AT_FDCWD, "*/etc/sysctl.conf*", O_RDONLY) = 3

/etc/sysctl.conf is read after /usr/lib/sysctl.d/protect-links.conf
That's what you wanted right?

I find this counter-intuitive: I would expect whatever I write in
> /etc/sysctl.conf to override distro defaults. This has historically
>
It does. See how it changes from 1 to 2, or am I missing something?
What is odd is it calls /etc/sysctl.conf twice, but that's due to the
symlink.

root@floyd:~# sysctl fs.protected_fifos
*fs.protected_fifos = 1*

root@floyd:~# grep fs.protected_fifos /etc/sysctl.conf
/usr/lib/sysctl.d/protect-links.conf
/etc/sysctl.conf:fs.protected_fifos = 2
/usr/lib/sysctl.d/protect-links.conf:fs.protected_fifos = 1

root@floyd:~# /sbin/sysctl --system
* Applying /usr/lib/sysctl.d/10-test1.conf ...
net.ipv6.neigh.default.base_reachable_time_ms = 20008
* Applying /usr/lib/sysctl.d/30-tracker.conf ...
fs.inotify.max_user_watches = 65536
* Applying /usr/lib/sysctl.d/50-bubblewrap.conf ...
kernel.unprivileged_userns_clone = 1
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
kernel.pid_max = 4194304
* Applying /etc/sysctl.d/99-sysctl.conf ...
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
fs.protected_fifos = 2
* Applying /etc/sysctl.d/999-test1.conf ...
** Applying /usr/lib/sysctl.d/protect-links.conf *...
*fs.protected_fifos = 1*
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
* *Applying /etc/sysctl.conf* ...
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
*fs.protected_fifos = 2*

root@floyd:~# sysctl fs.protected_fifos
f*s.protected_fifos = 2*


Bug#982436: procps: Please allow overriding protect-links.conf settings via /etc/sysctl.conf

2021-02-10 Thread intrigeri
Package: procps
Version: 2:3.3.17-1
Severity: normal
X-Debbugs-Cc: none

Hi,

I have set fs.protected_fifos=2 in /etc/sysctl.conf.
My intent is to override procps' protect-links.conf,
which sets fs.protected_fifos=1.

Under systemd, /etc/sysctl.conf is actually loaded via the
/etc/sysctl.d/99-sysctl.conf symlink, which sorts before
protect-links.conf, so the distro setting from protect-links.conf
overrides the custom value I've set in /etc/sysctl.conf.

I find this counter-intuitive: I would expect whatever I write in
/etc/sysctl.conf to override distro defaults. This has historically
been the case, and at least one system management tool I'm using (a
Puppet module) operates under the same assumption.

I understand this assumption still works fine in every other case in
Debian, because:

 - The name of the /etc/sysctl.d/99-sysctl.conf symlink starts with
   "99", which should sort last if all other such *.conf files have
   names that start with NN < 99.

 - All other packages that ship files in /usr/lib/sysctl.d/
   call these files NN-*.conf, with N < 99.

The only exception in the archive is procps, which does not use such
a numeric prefix, and thus makes this assumption incorrect wrt.
the contents of protect-links.conf.

Would you mind renaming protect-links.conf to NN-protect-links.conf,
with NN < 99?

Thanks for maintaining procps, and thanks in advance for considering
my request :)

Cheers!


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (2, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libncurses6  6.2+20201114-2
ii  libncursesw6 6.2+20201114-2
ii  libprocps8   2:3.3.17-1
ii  libtinfo66.2+20201114-2
ii  lsb-base 11.1.0

Versions of packages procps recommends:
ii  psmisc  23.4-2

procps suggests no packages.