Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

phunsoft
03.02.2021 15:15:26
drcux schrieb:

Ist es nicht besser, ....

Definitiv besser. Hab' nie darüber nachgedacht, dass eine Default-ACL die umask übersteuert. Wieder was gelernt. Danke für den Tip.

mabox
03.02.2021 14:15:15

Doch, sorry, das hab ich nicht eindeutig formuliert in meinem letzten Post glaub......
Es klappt tatsächlich auch über die ACL das die Datei die Gruppenberechtigung rw behält.
Ich habe zum testen jetzt unser Overrite Unit wieder gelöscht und den Apache neu gestartet. Kontrolliert ob der PID die umask 022 hat, hat er.
Danach über meine APP die Datei verändert und die hatte danach immer noch rw für die Gruppe.
Bei der Datei handelt es sich übrigens u.a. um ein KeePass Datenbankfile :-)

Von daher würde für mich jetzt auch die ACL Lösung tatsächlich funktionieren aber definitiv hab ich einiges gelernt mal wieder.......

eeLooDe8
03.02.2021 13:10:29
mabox schrieb:

Vermutlich ist die ACLs die "sauberste" da man am Apache nichts verbiegen muss........ bin mir aber auch nicht hundertprozentig sicher...

Versuch macht kluch... wie ich deinem Eingangsposting entnehme, wurden die Schreibrechte nach Zugriff durch die App für die Gruppe wieder zurückgesetzt. Da wäre es dann interessant zu wissen, ob es sich anders verhält, wenn die Defaultrechte des Ordners in der access-control-list auf einen Schreibzugriff gesetzt werden. Nach meinem Verständnis wirkt sich das nur auf die Anlage neuer Dateien aus, verhindert aber keine nachträgliche Änderung.

mabox
03.02.2021 12:57:28

Hallo drcux,
also ja, das klappt bei mir auch einwandfrei. Ich hatte am Anfang mal an ACL gedacht aber nicht weiterverfolgt und auch nicht mehr daran gedacht...... Irgendwie hab ich immer im Hinterkopf ACLs machen alles nur komplizierter. Zumindest wurde mir das auf irgendeinem Kurs mal so kommuniziert.......
Finde auch immer noch komisch das man im apache selbst da nicht ganz einfach was konifgurieren kann.
Vielen Dank für die Lösung. Dann haben wir jetzt also drei Lösungsansätze :-)
Vermutlich ist die ACLs die "sauberste" da man am Apache nichts verbiegen muss........ bin mir aber auch nicht hundertprozentig sicher...

drcux
03.02.2021 12:01:17

Ist es nicht besser, umask nur auf das Verzeichnis zu setzten, wo du es wirklich brauchst anstatt mit der Holzhammermethode Apache komplett umzustellen?

# mkdir testdir
# getfacl testdir/

user::rwx
group::r-x
other::r-x

# touch testdir/test1.txt
# ls -alh testdir/

-rw-r--r--  1 root root    0  3. Feb 10:53 test1.txt

# setfacl --default --modify group::rwx testdir/
# touch testdir/test2.txt

# ls -alh testdir/

-rw-r--r--   1 root root    0  3. Feb 10:53 test1.txt
-rw-rw-r--   1 root root    0  3. Feb 10:54 test2.txt

# getfacl testdir/

user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x
mabox
02.02.2021 19:20:59

Hallo Ihr Zwei,
also beide Varianten funktionieren bei mir auch, top!!!
Bei meinem ersten Test mit der umask im Unit File direkt hatte ich die Großschreibung nicht beachtet und "umask" geschrieben..... Das hat dann nicht gezogen.
Habe das jetzt nochmal alles durchgespielt und auch den PID dann überprüft ob es ankam.

Na dann hätten wir es ja eigentlich hätte ich gesagt oder? Im Prinzip jetzt halt über das systemd override.
Ich finde es dennoch komisch das es wohl nichts, zumindest einfaches, gibt das man z.B. direkt in der apache conf Datei eintragen um diese Berechtigung zu setzen.
Vielen Dank Euch für die Hilfe!!!

phunsoft
02.02.2021 18:50:56
eeLooDe8 schrieb:

Bei mir kommt die Änderung an:

# /etc/systemd/system/httpd.service.d/override.conf
[Service]
UMask=0002

Ja, so funktioniert das bei mir auch. Du hattest beim ersten Mal folgendes geschrieben:

eeLooDe8 schrieb:

Es geht noch einfacher, systemd unterstützt nämlich auch direkt das Setzen von Umgebungsvariablen => https://man.archlinux.org/man/systemd.service.5
Demnach müsst man das Drop-In-File nur um

[Service] 
Environment="umask=002"

Das Environment= hat tatsächlich die Environment-Variable umask mit dem Wert 002 erstellt, was aber für die umask wirkunslos ist.

Danke und Gruss
Peter

eeLooDe8
02.02.2021 18:16:47
phunsoft schrieb:

Liste Dir mal die Prozess-Ids der httpd Prozesse an und dann

cat /proc/"pid"/status | less

Wobei Du eine der Prozess-Ids statt dem "pid" einsetzt. Weit oben in der Liste wird die umask ausgewiesen.

Bei mir kommt die Änderung an:

# /etc/systemd/system/httpd.service.d/override.conf
[Service]
UMask=0002

Dann nach Neustart des Services

systemctl status httpd.service 
● httpd.service - Apache Web Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/httpd.service.d
             └─override.conf
     Active: active (running) since Tue 2021-02-02 16:59:30 CET; 11s ago
   Main PID: 2931 (httpd)
      Tasks: 82 (limit: 1152)
     Memory: 6.0M
     CGroup: /system.slice/httpd.service
             ├─2931 /usr/bin/httpd -k start -DFOREGROUND
             ├─2932 /usr/bin/httpd -k start -DFOREGROUND
             ├─2933 /usr/bin/httpd -k start -DFOREGROUND
             └─2934 /usr/bin/httpd -k start -DFOREGROUND

und anschliessender Ausgabe der umask:

cat /proc/2931/status|grep Um
Umask:  0002

Ohne die Änderung wurde 022 ausgegeben, also funktioniert es prinzipiell. Warum es bei "mabox" nicht so ist, weiß ich nicht. Eventuell soll er auch mal die Prüfung so wie von dir beschrieben vornehmen um zunächst Klarheit zu bekommen, dass die Änderung wirklich ankommt.

Mittels

systemctl edit --full httpd.service

habe ich eine volle Kopie -- nicht ein Dropin -- des Service Files erstellt

Ich würde dem override immer den Vorzug geben, weil dann nur dir wirklich relevanten Teile der Unit geändert werden. Wenn sich nämlich etwas entscheidendes (zB Abhängigkeiten) an den Original-units ändert, bekommst du das nie mit, weil die unit komplett und dauerhaft überschrieben würde.

Der override nur mit "UMask=002" scheint ja zu funktionieren. Damit hätte man dann auch nicht mehr das Problem, Änderungen an envvars verfolgen zu müssen

phunsoft
02.02.2021 17:57:54

Ich meine, eine funktionierende Konfiguration gefunden zu haben. Mittels

systemctl edit --full httpd.service

habe ich eine volle Kopie -- nicht ein Dropin -- des Service Files erstellt und darin folgendes angepasst:

  1. Type=simple in Type=forking geändert.

  2. An allen drei Stellen /usr/bin/httpd durch /usr/bin/apachectl ersetzt.

  3. In der Zeile ExecStart den Parameter -DFOREGROUND entfernt.

Der Ausschnitt sieht als folgendermassen aus:

[Service]
Type=forking
ExecStart=/usr/bin/apachectl start
ExecStop=/usr/bin/apachectl graceful-stop
ExecReload=/usr/bin/apachectl graceful

Der Parameter -DFOREGROUND sagt dem httpd, beim Startup keinen fork() zu machen, wie das Daemon Prozesse normalerweise tun. Im Standard httpd.service sagt Type=simple, dass der gestartete Prozess eben genau dies nicht tut, also der vom systemd gestartete Prozess am Laufen bleibt. Pass soweit.

Mit dem Start Skript apachectl will man dieses Verhalten nicht, denn sonst bleibt das Skript "hängen", bis der httpd Prozess endet. Also ohne -DFOREGROUND. So gestartet macht der httpd gleich zu Beginn einen fork(), der Parent Prozess endet und gibt die Kontrolle zurück an den apachectl, der seinerseits endet. Der Child vom initialen httpd bleibt dann als Hauptprozess am Laufen.

Mit dieser Einstellung funktioniert ein Starten und Stoppen vom httpd über systemctl soweit ohne Probleme. Allerdings habe das nur in meiner Testumgebung gemacht und da benutze ich den httpd nicht wirklich.

Bleibt also noch

umask 002

im File /usr/bin/envvars einzutragen und sich irgendwo eine Notiz zu machen, letzteres nach Updates jeweils zu überprüfen :-)

Gruss
Peter

phunsoft
02.02.2021 16:08:40
eeLooDe8 schrieb:

Ach so... ich dachte, es sei eine Umgebungsvariable, weil hier von envvars die Rede war, in dem eigentlich nur Umgebungsvariablen gesetzt werden.

Ja, der Name leitet irre, aber ein Blick in das apachectl Script zeigt, dass das File /usr/bin/envvars "sourced" wird, d.h. als Shell Script im laufenden Shell Prozess (=apachectl) eingebunden wird. Somit können nicht nur Umgebungsvariablen dort gesetzt, sondern alle (sinnvollen) Shell Befehle ausgeführt werden.

Ein grosser Schwachpunkt der apachectl ist, dass nur das zur Installation gehördende File /usr/bin/envvars gesucht und ausgeführt wird. Das File wird bei einem Update vom Apache wohl neu gespeichert und eigene Modifikationen gehen verloren. Schade. Es wäre schön, wenn ein File im /etc vorgeschalten worden wäre, wie sonst so üblich.

mabox
02.02.2021 16:00:58
eeLooDe8 schrieb:

Möglich wäre dann auch ein Drop-In mit dem Inhalt

[Service]
UMask=002

Ob die Erweiterung ankommt und funktioniert, konnte ich allerdings nicht testet, der Service startet aber

Das hab ich vorhin getestet, hatte aber nichts gebracht. Service ist bei mir auch gestartet.

phunsoft
02.02.2021 15:59:50
eeLooDe8 schrieb:

Ob die Erweiterung ankommt und funktioniert, konnte ich allerdings nicht testet, der Service startet aber

Liste Dir mal die Prozess-Ids der httpd Prozesse an und dann

cat /proc/"pid"/status | less

Wobei Du eine der Prozess-Ids statt dem "pid" einsetzt. Weit oben in der Liste wird die umask ausgewiesen.

eeLooDe8
02.02.2021 15:53:12
phunsoft schrieb:

Die umask ist keine Umgebungsvariable, sondern ein prozessbezogener Wert, der mittels umask() System Call, bzw. dem umask Shell Utility gestzt wird.

Ach so... ich dachte, es sei eine Umgebungsvariable, weil hier von envvars die Rede war, in dem eigentlich nur Umgebungsvariablen gesetzt werden.
Möglich wäre dann auch ein Drop-In mit dem Inhalt

[Service]
UMask=002

Ob die Erweiterung ankommt und funktioniert, konnte ich allerdings nicht testet, der Service startet aber

mabox
02.02.2021 15:50:07

Super, vielen Dank phunsoft, ich in bin gespannt und probiere auch weiter :-)

phunsoft
02.02.2021 15:47:43

Ich habe inzwischen mit

systemctl edit --full httpd.service

eine Kopie des Service Scripts im /etc... erstellt und dort statt usr/bin/httpd das Script /usr/bin/apachectl eingetragen. Funktioniert leider (noch) nicht. Das Starten des httpd geht, aber nach den Stop zeigt

systemctl status httpd

Fehler an. Habe bisher mit Type=simple und Type=exec versucht. Ich bin da noch zu wenig sattelfest mit dem systemd und dem Verhalten vom httpd. Melde mich wieder, wenn ich was funktionierendes habe.

Fußzeile des Forums

Powered by FluxBB