ACLs und truncate

0 views
Skip to first unread message

Christian Garbs

unread,
Sep 4, 2021, 2:27:16 PMSep 4
to
Mahlzeit!

Ich habe eine Textdatei mit etwas Inhalt:

| $ ls -lh /tmp/irc_message_container_borg
| -rw-rw----+ 1 borg borg 84 4. Sep 03:38 /tmp/irc_message_container_borg


Da mein User (mitch) die Datei nicht angelegt hat, aber mir ihr
arbeiten soll, hat sie ACLs bekommen, die mir Schreib- und Leserechte
geben:

| $ whoami
| mitch

| $ getfacl /tmp/irc_message_container_borg
| getfacl: Removing leading '/' from absolute path names
| # file: tmp/irc_message_container_borg
| # owner: borg
| # group: borg
| user::rw-
| user:mitch:rw-
| group::---
| mask::rw-
| other::---


Ich kann die Datei dank der ACL wie erwartet lesen:

| $ wc /tmp/irc_message_container_borg
| 1 13 84 /tmp/irc_message_container_borg


Ich kann sie aber nicht schreiben - weder etwas anhängen, noch sie
leeren (ohne sie zu löschen):

| $ echo blabla >> /tmp/irc_message_container_borg
| bash: /tmp/irc_message_container_borg: Permission denied

| $ truncate --size 0 /tmp/irc_message_container_borg
| truncate: cannot open '/tmp/irc_message_container_borg' for writing: Permission denied


Warum klappt das 'r' aus der ACL, das 'w' aber nicht?

Liegt das am Sticky-Bit von /tmp, was dann zu 'restricted deletion'
führt? Aber ich will ja kein Datei deleten, ich will die bestehende
Datei appenden und truncaten, ohne den Directory-Eintrag zu verändern.

Was übersehe ich hier?

Danke und Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

"Faith: not *wanting* to know what is true."
-- Friedrich Nietzsche

Thomas Dorner

unread,
Sep 5, 2021, 7:08:03 AMSep 5
to
Hallo Christian!

Christian Garbs <mi...@cgarbs.de> writes:
> | $ echo blabla >> /tmp/irc_message_container_borg
> | bash: /tmp/irc_message_container_borg: Permission denied

/tmp Schreibzugriffe sind seit einigen Jahren per default schon im Kernel
eingeschränkt (auch bei Gruppenschreibrechten). Schau mal nach, ob es
bei Dir /proc/sys/fs/protected_regular gibt, dann ist das per default
so. In diesem Fall liefert ein "sysctl fs.protected_regular" (als root
oder per sudo) vermutlich den Wert 1. Mit 0 würde es gehen, also:

sysctl fs.protected_regular=0

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

Christian Garbs

unread,
Sep 5, 2021, 4:09:47 PMSep 5
to
Mahlzeit!

Thomas Dorner <de.comp.os.unix.linu...@spamgourmet.com> wrote:
> Hallo Christian!
>
> Christian Garbs <mi...@cgarbs.de> writes:
>> | $ echo blabla >> /tmp/irc_message_container_borg
>> | bash: /tmp/irc_message_container_borg: Permission denied
>
> /tmp Schreibzugriffe sind seit einigen Jahren per default schon im Kernel
> eingeschränkt (auch bei Gruppenschreibrechten). Schau mal nach, ob es
> bei Dir /proc/sys/fs/protected_regular gibt, dann ist das per default
> so.

Ah, danke!

Hätte ich irgendeine Chance gehabt, die Info in einer Manpage zu
finden? Ich wahr schon froh, in chmod(1) etwas zur restricted
deletion gefunden zu haben…

Ich habe bereits einen Plan, wie ich an der Stelle ganz ohne
Userwechsel auskommen könnte, aber wenn sich das auf /tmp beschränkt,
kann ich ja mal /var/run oder /var/tmp ausprobieren. Letzteres hätte
sogar den Vorteil, dass unversendete Daten einen Reboot überleben
würden (nicht, dass das wichtig wäre - aber nett).

Vielen Dank!
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
"Man sollte keine Dummheit zwei Mal begehen; die Auswahl ist groß genug."
(Jean Paul Sartre)

Thomas Dorner

unread,
Sep 6, 2021, 9:08:03 AMSep 6
to
> Hätte ich irgendeine Chance gehabt, die Info in einer Manpage zu
> finden?

Vermutlich nicht, da die Änderung ja im Kernel steckt, und nicht in
irgendeiner Applikation. Mir ist sie damals sofort nach dem Reboot mit
neuem Kernel aufgefallen, da die Log-Dateien meiner
Applikations-Container auf /tmp liegen, und eigentlich von den start-up
Skripts in- und außerhalb des Containers geschrieben werden. Innerhalb
ging plötzlich nicht mehr. Und ich hatte auch nur ganz normale
Gruppenschreibrechte vergeben.

> Vielen Dank!

Bitte. :-)
Reply all
Reply to author
Forward
0 new messages