Ich habe noch ein weiteres frustrierendes Problem. Ich habe eine Gruppe von Benutzern, die zur Gruppe „Testing“ gehören. Ich habe einen Ordner unter /var/log/projects, bei dem das Setgid-Bit gesetzt ist. Dadurch behalten alle neuen Dateien oder Ordner, die in /projects erstellt werden, immer den Gruppenbesitz von „Testing“.
[root@system log]# ll | grep projects
drwxr-s---. 4 root testing 4096 Jun 10 19:36 projects
Wenn ich eine Datei berühre oder einen Ordner in diesem Verzeichnis erstelle, erben sie die richtigen Berechtigungen und Eigentümer.
[root@system log]# touch /var/log/projects/testfile
[root@system log]# ll /var/log/projects/
total 4
-rw-r--r--. 1 root testing 0 Jun 10 19:49 testfile
Und wenn ich einen neuen Ordner erstelle, funktioniert es wie erwartet.
[root@system projects]# mkdir folder1
[root@system projects]# ll
total 8
drwxr-sr-x. 2 root testing 4096 Jun 10 19:52 folder1
-rw-r--r--. 1 root testing 0 Jun 10 19:49 testfile
So weit, so gut. Allerdings verwende ich diesen Ordner für Remote-Syslogs von anderen Systemen. Wenn ich den Dienst rsyslogd starte, erben alle von diesem Prozess erstellten Dateiordner den Besitz von root:root.
drwx--S---. 2 root root 4096 Jun 10 19:44 remotehost
Ich war der Meinung, dass der Zweck des Setgid-Bits für meinen Anwendungsfall war. Kann mir jemand sagen, was ich falsch mache oder wie ich das beheben kann, sodass alle vom rsyslogd-Prozess erstellten Ordner/Dateien den Gruppenbesitz „testing“ haben? Dies ist auf einem RHEL 6-Server.
Antwort1
Die von Ihnen gewählte Methode würde mit Programmen funktionieren, die ihre Ausgabeberechtigungen und Eigentümer nicht speziell verwalten, rsyslogd hingegen schon.
RsyslogdDokumentationsseite zum Ausgabemodulzeigt, dass Sie mit der fileGroup [groupName]Konfigurationsdirektive den Standardwert für die Gruppe der Ausgabedatei festlegen können.
Antwort2
Da rsyslog Setgid-Sticky-Bits ignoriert, konnte ich das Problem beheben, indem ich in meiner benutzerdefinierten Vorlagenkonfiguration rsyslogd.conf die folgenden Anweisungen verwendete:
$template TmplAuth, "/var/log/projects/%FROMHOST-IP%/%PROGRAMNAME%.log"
$template TmplMsg, "/var/log/projects/%FROMHOST-IP%/%PROGRAMNAME%.log"
$umask 0000
$DirCreateMode 0750
$FileCreateMode 0640
$FileGroup testing
$DirGroup testing
authpriv.* ?TmplAuth
*.info,mail.none,authpriv.none,cron.none ?TmplMsg
HINWEIS: $DirCreateMode und $FileCreateMode funktionieren nicht, bis Sie die Standard-Umask mit der Direktive $umask 0000 überschreiben.