Your message dated Wed, 22 Dec 2021 08:15:20 +1100
with message-id
<caly8cw7187rzh55qshv7ubv5u9gdj5ek-fas_52-apujt17...@mail.gmail.com>
and subject line Re: Bug#1002064: default kernel setting protected_regular=2
breaks file system access and is hard to fix
has caused the Debian Bug report #1002064,
regarding default kernel setting protected_regular=2 breaks file system access
and is hard to fix
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.)
--
1002064: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002064
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: procps
Version: 2:3.3.17-5
Package: systemd
Version: 247.3-6
Debian 11 introduces a new feature, that prevents users from writing to files
that they don't own ignoring the file permissions
(see https://github.com/torvalds/linux/commit/30aba6656f ).
1. I think, that should not be the default behaviour but opt in.
2. If you fix it (write "fs.protected_regular=0" to /etc/sysctl.conf) that fix
should work.
The packages procps contains the file /usr/lib/sysctl.d/protect-links.conf with
the line
"fs.protected_regular = 2" that is loaded after /etc/sysctl.conf and breaks the
fix.
If I remove / alter the file in /usr/lib/sysctl.d, it may be overwritten with
the next update.
I don't know who's to blaim, systemd not loading the files in a sensible order
or
procps for putting the file in the wrong place? I suspect it's systemd, /etc/*
should
override /usr/* ?
A side note: I found no mention of this in the release notes or anyhwere els on
a debian site. For a change that severe, some documentation would have been
helpful.
Suggestion: put a commented line in /etc/sysctl.conf
smime.p7s
Description: S/MIME Cryptographic Signature
--- End Message ---
--- Begin Message ---
On Wed, 22 Dec 2021 at 07:50, Daniel Feuchtinger <[email protected]>
wrote:
> Am 21.12.21 um 12:10 schrieb Ansgar:
> > I disagree: it is a sensible change. If you want an insecure
> > configuration, you should have to explicitly configure your system to
> > be so.
>
> If you say so... Try a users perspective:
> You try to write to a file and it does not work (funny: touch does work)
> You check the file permissions
> You check the extended attributes
> You search for erros and logs
> You check app armor
> You check the debian release notes
> You search for strange security features, breaking basic file system
> functionality
>
There are two issues here.
The first is the configuration file is not following the systemd standard,
this is covered in bug #100908 and fixed in procps 3.3.17-6
This doesn't mean it's impossible or difficult to change the settings at
all, using the standard put the same file in /etc fixes it; or even
anything with a filename that comes after p will do it.
It does mean putting something in /etc/sysctl.conf won't override it.
Whether or not should the system sysctl actually read /etc/sysctl.conf
last like procps sysctl does without the hacky symlink isn't that important
here; though it does contribute to the problem.
So, issue #1 is covered by bug #100908.
Next, should the default setting be fs.protected_regular=0? There are good
reasons for this setting and the commit message gives a lot of them. This
is a file in a world-writable sticky directory that is trying to be opened
by someone who doesn't own the file.
Yes it's annoying there is no message about it in the kernel (it's the one
stopping the action after all) but it's better to have that protection than
without it.
I'd say issue #2 is not an issue; perhaps some release notes would help but
for the great majority of people it's a non-issue.
Anyway, you might as well close this bug, if there's no
> chance of changing the default behaviour. I guess for
>
Done.
- Craig
--- End Message ---
