DSM 6.x und darunter DSM | rm.log | trotz root nicht zu löschen

[peterhoffmann]

Durch Zufall bin ich über eine rm.log im Verzeichnis /var/log gestolpert, die es früher so nicht gab.
Geloggt werden alle gelöschten Dateien.
Beispiel:

[...]
2021-12-19T11:06:45+01:00 DS716 rm: uid: 0, euid: 0, arguments:["-f" "/volume1/wolke/server1/xxxx/backup-xxx-20210926.tgz"]
2021-12-19T11:10:26+01:00 DS716 rm: uid: 0, euid: 0, arguments:["-f" "/volume1/wolke/server2/xxxx/backup-xxx-20210926.tgz"]
[...]
2022-01-15T11:46:54+01:00 DS716 rm: uid: 0, euid: 0, arguments:["-rf" "/volume2/@tmp/codesign_keyringxxxxxx"]
2022-01-15T11:46:56+01:00 DS716 rm: uid: 0, euid: 0, arguments:["-rf" "/volume2/@tmp/codesign_keyringxxxxxx"]
2022-01-15T11:49:29+01:00 DS716 rm: uid: 0, euid: 0, arguments:["-f" "/etc/avahi/services/webdav_https.service"]
[...]

Nach etwas Suche im System fand ich folgende zwei Konfi-Dateien (aus März 2021):

/etc.defaults/syslog-ng/patterndb.d/rm.conf
/etc/syslog-ng/patterndb.d/rm.conf

Folgender Inhalt in beiden Dateien:

destination d_rm_log { file("/var/log/rm.log"); };

filter f_rm_info {
  program("^rm$");
};

log { source(src); filter(f_rm_info); destination(d_rm_log); };

Ok, dachte ich mir, da hat Synology ein Log für das Löschen irgendwann eingefügt.

Ich wollte die Logs löschen, Pustekuchen, trotz root bekam ich eine Fehlermeldung:

root@DS716+ /var/log $ rm rm.log
rm: cannot remove ‘rm.log’: Operation not permitted

Ich bin es ja gewohnt mit root-Rechten alles tun zu dürfen, aber auch gleichzeitig für alles Handeln verantwortlich zu sein. Womit ich gar nicht umgehen kann, wenn ich mit root-Rechten etwas nicht darf.

Aber mal im Ernst:

Ist das rm.log euch schon bekannt?
Warum darf/kann ich das nicht löschen?

 

[Benares]

Grad mal gegoogelt. Ich vermute, dass es daran liegt:

root@DS415:/var/log# lsattr rm.log
-----a--------e--- rm.log

Es liegt wohl an diesem a-Flag


Tante Google sagt dazu

a A file with the 'a' attribute set can only be opened in
append mode for writing. Only the superuser or a process
possessing the CAP_LINUX_IMMUTABLE capability can set or
clear this attribute.

Mit einem eigenen Log-File konnte ich das nachvollziehen:

root@DS415:/var/log# touch xxx.log
root@DS415:/var/log# chattr +a xxx.log
root@DS415:/var/log# rm xxx.log
rm: cannot remove 'xxx.log': Operation not permitted
root@DS415:/var/log# chattr -a xxx.log
root@DS415:/var/log# rm xxx.log

 

[peterhoffmann]

@Benares
Danke. Du hast mir meine Gotteskräfte (root) wiedergegeben.

root@DS716+ /var/log $ lsattr rm.log
-----a-------e-- rm.log
root@DS716+ /var/log $ chattr -a rm.log
root@DS716+ /var/log $ rm rm.log
root@DS716+ /var/log $

Natürlich legt er gleich eine neue rm.log an, die die gerade frisch getätigte Löschung von rm.log enthält:

2022-01-16T14:50:47+01:00 DS716 rm: uid: 0, euid: 0, arguments:["rm.log"]

Interessant finde ich, dass er bei der neuen rm.log kein a-flag mehr setzt:

root@DS716+ /var/log $ lsattr rm.log
-------------e-- rm.log

 

[Benares]

Wenn du dich bzw. die Datei vor deinen Gotteskräften schützen möchtest, kannst du ja das a-Flag wieder setzen