Your message dated Mon, 20 Apr 2020 19:54:09 +0200
with message-id <20200420175409.ga405...@aurel32.net>
and subject line Bug#954230: libc6: In a sticky directory root cannot write to 
files owned by normal users
has caused the Debian Bug report #954230,
regarding libc6: In a sticky directory root cannot write to files owned by 
normal users
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 ow...@bugs.debian.org
immediately.)


-- 
954230: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954230
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.30-2
Severity: important

Dear Maintainer,

after I installed libc6 2.30-2 today I observed that root could not
write to files in /tmp owned by other users. For example, if I have a
file

-rw-r--r-- 1 ziegler ziegler 3 Mar 18 22:31 /tmp/foo ,

then, if root (!) issues the command

  echo 123 > /tmp/foo ,

I get "-bash: /tmp/foo: Permission denied".

Likewise root cannot change /tmp/foo with editors like nano, vi or
emacs.




The same happens in any sticky directory owned by root. For example if
I have in my home directory the directory

drwxrwxrwt 1 root root  0 Mär 18 22:56 sticky

containing

-rw-r--r-- 1 ziegler ziegler 2 Mar 18 23:02 sticky/foo ,

then root cannot write to this file.


The version 2.31-0experimental0 shows the same behaviour. Note that
I am not sure that libc6 is the culprit.

Regards,
Martin



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.15-1
ii  libgcc-s1  10-20200312-2

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.73
pn  glibc-doc              <none>
ii  libc-l10n              2.30-2
ii  locales                2.30-2

-- debconf information:
  glibc/restart-services:
* glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: true
  glibc/disable-screensaver:
  glibc/restart-failed:

--- End Message ---
--- Begin Message ---
control: reassign 954230 procps:
control: retitle 954230 procps: In a sticky directory root cannot write to 
files owned by normal users


Hi,

For some reason I don't get this bug has not been sent to the
debian-glibc@lists.debian.org and is also not on the list archive.

I am therefore discovering it now.

On 2020-03-18 23:13, zieg...@uni-freiburg.de wrote:
> Package: libc6
> Version: 2.30-2
> Severity: important
> 
> Dear Maintainer,
> 
> after I installed libc6 2.30-2 today I observed that root could not
> write to files in /tmp owned by other users. For example, if I have a
> file
> 
> -rw-r--r-- 1 ziegler ziegler 3 Mar 18 22:31 /tmp/foo ,
> 
> then, if root (!) issues the command
> 
>   echo 123 > /tmp/foo ,
> 
> I get "-bash: /tmp/foo: Permission denied".
> 
> Likewise root cannot change /tmp/foo with editors like nano, vi or
> emacs.

Thanks for your analysis Matthias and Richard. This is indeed due to the
link protection and has nothing to do with glibc.

The behaviour has been changed in procps version 2:3.3.16-1, see
bug#914859 for more background. This is done by the file
/usr/lib/sysctl.d/protect-links.conf.

Martin you can revert to the previous behaviour with:
echo 0 > /proc/sys/fs/protected_regular.

This is therefore not a bug but a wanted behaviour of procps. I am
therefore closing the bug and reassigning it to this package.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: PGP signature


--- End Message ---

Reply via email to