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
On Mi, 09 dec 20, 16:46:17, MichaIng wrote:
> 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 the
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
On Ma, 08 dec 20, 15:57:17, 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
> -ba
On Ma, 08 dec 20, 16:45:08, MichaIng wrote:
>
> Jep, based on the way the list mail address was shown on the Debian bug
> report page, I was actually hoping to reach official maintainers, but this
> seems to be more an end-user support list?
Yes, this is an end-user support list.
The idea is tha
On Wed, Dec 09, 2020 at 12:02:17AM +0100, MichaIng wrote:
> Sharing files through /tmp is probably rare, but /tmp it is for temporary
> files, it's by default a tmpfs
No, it's not. It's just a directory inside the root file system by
default, in Debian.
> (relevant when one wants to minimize fil
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
On Tue, Dec 08, 2020 at 09:50:32PM +0100, MichaIng wrote:
> And, root should IMO still be allowed to do it, as practically it can anyway
> via chown. root can as well remove any file, regardless of sticky bit, so
> this would be consistent.
Unexpected clobberin' by root is the actual *worst* case
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
On Tue, Dec 08, 2020 at 06:40:38PM +0100, to...@tuxteam.de wrote:
> I lost track a bit about your other hypotheses, but this mode changing
> bit when O_CREAT is given somehow rings a bell.
I googled "linux o_creat sticky" and got this:
https://patchwork.kernel.org/project/kernel-hardening/patch/2
On Tue, Dec 08, 2020 at 06:08:12PM +0100, MichaIng wrote:
> 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 seem
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
On Tue, Dec 08, 2020 at 05:09:09PM +0100, MichaIng wrote:
[...]
> >>dash: 1: cannot create testfile: Permission denied
> >
> >Oh, I see. Strange error message though -- I'd expect dash to
> >try to open the file in append mode, not to `create' it.
> I was also wondering about that, but dash prin
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
On Tue, Dec 08, 2020 at 03:57:17PM +0100, MichaIng wrote:
[...]
> @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 creat
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
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/tes
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
On Fri, Dec 04, 2020 at 02:40:02PM +0100, MichaIng wrote:
> 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-04 14:16:58 root@micha:/tmp# whoami
> root
"id" is a better command for determining your c
On Fri, Dec 04, 2020 at 02:40:02PM +0100, MichaIng wrote:
> 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
20 matches
Mail list logo
