Re: Where to report: root fails to edit other users file in sticky bit directory

[Greg Wooledge <wooledg@eeg.ccf.org>]

On Tue, Dec 08, 2020 at 03:57:17PM +0100, MichaIng wrote:
> root@VM-Bullseye:/tmp# cd /root
> root@VM-Bullseye:~# mkdir testdir
> root@VM-Bullseye:~# chmod 1777 testdir
> root@VM-Bullseye:~# > testdir/testfile
> root@VM-Bullseye:~# chown www-data testdir/testfile
> root@VM-Bullseye:~# > testdir/testfile
> -bash: testdir/testfile: Permission denied
> -------
> The issue is not related to the file system and not related to the kernel
> version.

It *has* to be related to the kernel.  Where else would the permissions
(capabilities) be applied?

> As said I tested in on RPi with their current stable Linux 5.4 (now
> with a second recent update) and on Bullseye with now as well two kernel
> versions. But to be sure, I'll downgrade the kernel to a previous major
> version, probably from Buster backports, just to be sure.

But you didn't try it with buster's kernel yet?

For that matter, how did you run this shell process?  I see "VM" in
your shell prompt, so I'm guessing it's something far more complex
than "I booted my bullseye system, and logged in on the console as root".

Is there any possibility that the way you invoked your shell process
is messing with the capabilities(7) in such a way that you lost (or
never got) CAP_FOWNER?

If it's not that, then someone's going to have to try to reproduce your
results, which would mean running a post-stable kernel, which means
"not me".

(Also... "their current stable Linux 5.4" -- ????  Is this even DEBIAN?!
If this is a Raspbian or something, you're posting on the wrong mailing
list.)