Your message dated Sat, 19 Aug 2023 15:58:47 +1000
with message-id
<caly8cw48exyda_4qj+my87oinppde6rcw77saqfzbw6z7r7...@mail.gmail.com>
and subject line Re: Bug#997930: procps: sysctl fails writing to non-namespaced
sysctls in a container
has caused the Debian Bug report #997930,
regarding procps: sysctl fails writing to non-namespaced sysctls in a container
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
997930: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997930
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: procps
Version: 2:3.3.17-5
Severity: important
Tags: patch
X-Debbugs-Cc: [email protected]
Dear Maintainer,
* What led up to the situation?
Installing a package that runs sysctl -p in its postinst script fails
with a non-zero exit status.
* What exactly did you do (or not do) that was effective (or
ineffective)?
# cat /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf
kernel.shmmax = 17179869184
# sysctl -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf
* What was the outcome of this action?
sysctl: permission denied on key "kernel.shmmax"
* What outcome did you expect instead?
sysctl: permission denied on key "kernel.shmmax", ignoring
Patches are available in Ubuntu, but have not been backported to Debian.
The absence of these in Debian makes running services that expect host
system access in LXC containers untenable.
https://git.launchpad.net/ubuntu/+source/procps/tree/debian/patches/ignore_eaccess.patch?h=applied/ubuntu/focal-devel
https://git.launchpad.net/ubuntu/+source/procps/tree/debian/patches/ignore_erofs.patch?h=applied/ubuntu/focal-devel
Index: procps-3.3.16/sysctl.c
===================================================================
--- procps-3.3.16.orig/sysctl.c
+++ procps-3.3.16/sysctl.c
@@ -459,6 +459,7 @@ static int WriteSetting(const char *sett
case EPERM:
case EROFS:
case EACCES:
+ ignore_failure = true;
xwarnx(_("permission denied on key \"%s\"%s"), outname,
(ignore_failure?_(", ignoring"):""));
break;
default:
Index: procps-3.3.16/sysctl.c
===================================================================
--- procps-3.3.16.orig/sysctl.c
+++ procps-3.3.16/sysctl.c
@@ -457,11 +457,12 @@ static int WriteSetting(const char *sett
}
break;
case EPERM:
- case EROFS:
case EACCES:
ignore_failure = true;
xwarnx(_("permission denied on key \"%s\"%s"), outname,
(ignore_failure?_(", ignoring"):""));
break;
+ case EROFS:
+ ignore_failure = true;
default:
xwarn(_("setting key \"%s\"%s"), outname,
(ignore_failure?_(", ignoring"):""));
break;
-- System Information:
Debian Release: 11.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-9-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages procps depends on:
ii init-system-helpers 1.60
ii libc6 2.31-13+deb11u2
ii libncurses6 6.2+20201114-2
ii libncursesw6 6.2+20201114-2
ii libprocps8 2:3.3.17-5
ii libtinfo6 6.2+20201114-2
ii lsb-base 11.1.0
Versions of packages procps recommends:
ii psmisc 23.4-2
procps suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi
I've looked at this bug report again. Just ignoring errors is a terrible
idea and the patches are not consistent with the intent anyway. sysctl
should error out if it gets permission denied on a key.
- Craig
On Sun, 14 Nov 2021 at 17:23, Craig Small <[email protected]> wrote:
> On Wed, 27 Oct 2021 at 21:24, Iain Buclaw <[email protected]> wrote:
>
>> Installing a package that runs sysctl -p in its postinst script fails
>> with a non-zero exit status.
>>
> That is probably what is supposed to happen. However, it looks like
> read-only /sys filesystems are a thing. Leaving aside what a container
> should or shouldn't do, there are some issues with the patches, mainly they
> don't say what they actually are doing.
>
>
>> https://git.launchpad.net/ubuntu/+source/procps/tree/debian/patches/ignore_eaccess.patch?h=applied/ubuntu/focal-devel
>
> This patch states that it ignores EACCESS however it also ignores EROFS
> and EPERM as well. Was this the intent of the patch?
>
>
>> https://git.launchpad.net/ubuntu/+source/procps/tree/debian/patches/ignore_erofs.patch?h=applied/ubuntu/focal-devel
>
> This patch states that it ignores EROFS. It actually doesn't do this but
> changes the error message only.
>
> In a case statement, if there is no break then the program falls through
> to the next line, so putting ignore_failure after EACESS also means we have
> ignore_failure for EROFS and EPERM as well.
> I'm not sure why you would change the error message (patch #2).
>
> So, looks like there was a bit of just try it until it works going on,
> with the added bonus sysctl says permission denied for 3 different error
> messages. Mixed in with this is referenced bug #1157643 also mentions the
> issue is EINVAL and not the other two or three error codes we have already
> discussed.
>
> It doesn't look like the patches were tested that well beyond fixing the
> issue and completely ignoring the return code for fprocopen would do the
> same thing.
> I think that the real problem is that LXC has a read-only /sys and
> fprocopen returns EROFS and this is the only one that needs to be bypassed
> but I'm not sure. That would be a much simpler thing to check and ignore.
>
> Running a strace on the sysctl program in an LXC container and finding the
> return code of the open (it might be a fopencookie() or an openat()
> instead) on the offending key should clear it up pretty quickly.
>
> - Craig
>
>
>
--- End Message ---
