Your right /tmp is not a tmpfs by default on Debian. I though it was,
maybe being too much used to it as this is configured by default on our
images. /dev/shm or /run would work better then, although /run IMO is
more aimed for non-temporary files, relevant through the whole runtime
of the relat
Please note that it by default appears on Bullseye only. See that last
mails regarding this issue, the related changed sysfs setting has
identified already do:
---
sysctl fs.protected_regular=2
---
and retry the steps, which will then fail.
---
sysctl fs.protected_regular=0
---
t
Am 08.12.2020 um 22:03 schrieb Greg Wooledge:
Unexpected clobberin' by root is the actual *worst* case that this
security feature is trying to protect against. Imagine this hypothetical
scenario:
1) Process A running as regular user alice creates a temp file in /tmp,
owned by alice.
2) Dum
I think the topic with the modes just applies when the file is actually
created, hence not existing yet.
However, aiming for a method to edit a file without O_CREAT, and voila:
---
root@VM-Bullseye:~# cat testdir/testfile
143
root@VM-Bullseye:~# sed -i 's/1/5/' testdir/testfile
root@VM-Bulls
Good idea, although it would have been recognised much earlier during
nearly every normal system operation:
---
root@micha:/tmp# set -o | grep noclobber
noclobber off
---
strace is a fantastic idea, but it seems to fail on the lowest level
"EACCES (Permission denied)":
---
ro
Am 08.12.2020 um 16:55 schrieb to...@tuxteam.de:
@Tomas:
---
root@VM-Bullseye:/tmp# id
uid=0(root) gid=0(root) groups=0(root)
root@VM-Bullseye:/tmp# >> testfile
-bash: testfile: Permission denied
root@VM-Bullseye:/tmp# dash -c '>> testfile'
dash: 1: cannot create testfile: Permission denied
Am 08.12.2020 um 16:15 schrieb Greg Wooledge:
It *has* to be related to the kernel. Where else would the permissions
(capabilities) be applied?
That is exactly what I am wondering about. Those are pretty minimal
Debian install, no SELinux and no AppArmor actively installed, only what
is pull
Sorry for the late reply guys, I was not subscribed to the list, just
got the address from the bug report instructions in case the related
package could not be identified, and thought I get an answer directly to
my mailbox xD: https://www.debian.org/Bugs/Reporting.en.html
Back to topic.
I tot
Hi Debian team,
I'm sorry to contact you here, but I ran into an IMO extremely important
bug where I don't know which package is actually responsible.
Even the root user is not permitted to write to an existing file that is
owned by another user within a sticky bit directory:
---
2020-12
9 matches
Mail list logo
