Default-umask für Benutzer

[bbastix]

Hallo.

Wie kann ich denn einem Benutzer eine umask von 007 verpassen? Ich hab die /etc/login.defs angepasst, ebenso die /etc/profile und die .bash_profile des Benutzers. Aber seine umask ist und bleibt auf 022, auch wenn ich ihn neu anmelde.

Wo muss ich die denn noch umstellen?

Basti

Debian Sarge

[bbastix]

...in die /et/passwd hab ich auch umask=007 gesetzt, aber irgendwo wird die entweder wieder au 022 zurückgesetzt oder das 007 wird an all den Stellen, die mir genannt wurden ignoriert.

Argh!

Basti

[Maikel]

Guck mal in

Code: Alles auswählen

/etc/skel/.bash_profil

bzw direkt in

Code: Alles auswählen

/etc/login.defs

.
Dahin wird ja für den default-Wert verwiesen.

[bbastix]

Hab ich ja angepasst.

[Maikel]

Und wenn du nun ne neue Datei erstellst passt das nicht?

[bbastix]

Nein, er setzt die Rechte dann auf rwx-r-r, ganz gleich, ob ich den Benutzer neu angemeldet habe oder gar einen neuen Benutzer angelegt habe, den Rechner neu gestartet habe oder einen Kopfstand gemacht habe. Woran könnte das liegen? Wie kann ich die "Fehlerquelle" eingrenzen?

Basti

[Maikel]

Und wenn du nun ne neue Datei erstellst passt das nicht?

IMHO greift das nur auf neu erstellt Datein.

[bbastix]

Und wenn du nun ne neue Datei erstellst passt das nicht?

IMHO greift das nur auf neu erstellt Datein.

Ja, sollte es zumindest - tut es aber nicht. Sch*** - ich hab einfach Sarge per Netinstall-CD und ein paar Office-Programme installiert!

Hat denn niemand mal das gleiche Problem gehabt oder gibts eine andere Möglichkeit, ein Gruppenverzeicnis anzulegen, auf das dann alle Gruppenmitglieder frei Zugreifen können?

Basti

[gms]

Ich habe jetzt die /etc/profiles geändert und eine neue Datei in /etc/X11/Xsession.d/99umask angelegt, in beide ein "umask 0007" eingetragen und es funktioniert bei mir.
Es gibt allerdings auch Ausnahmen, z.B. Nautilus kocht anscheinend ein eigenes Süppchen. letztendlich ist die umask ja auch nur ein Vorschlag (default Wert). Die Rechte vergibt im Endeffekt das Programm, welches die Datei erstellt.

[edit]
Die Datei /etc/X11/Xsession.d/99umask muß mit Leserechten für alle ausgestattet sein.
[/edit]

[bbastix]

Ja, jetzt funktioniert es. Herzlichen Dank! Ich hatte wohl fahrlässigerweise je die führende 0 weggelassen, da einmal 022 ohne 0 davor vorgeschlagen wurde und ich mir dachte: Oktal 07 ist das gleiche, wie 007, aber offenbar wurde da die Zeichenkette, nicht die Oktalzahl ausgewertet.

Jetzt wäre natürlich noch ein kleines Shell-Skript schön, welches bei jedem Login aufgerufen wird und die Rechte der Gruppen-Verzeichnisse nochmal "nachrückt", falls da doch irgendwie was schief gegangen ist.

Vielen Dank.
Basti

[Fentanyl]

Das hier:

Code: Alles auswählen

find / -type d -uid UID ! -perm 770 -exec chmod 770 {} \;

sollte helfen, wobei UID durch die uid des entsprechenden benutzers zu ersetzen ist und man noch zusätzliche einstellungen vornehmen kann (z.B. auf bestimmte verzeichnisse begrenzen, da eine Suche ab / relativ zeitintensiv ist.

MfG; Fenta

[bbastix]

Hi.

Es gibt ein Verzeichnis /home/groups. Darin liegt für jede Arbeitsgruppe je ein Unterverzeichnis mit dem Namen der Gruppe. Ich dachte daher sowas in der Art:

# Schleife durch jeden Eintrag in /home/groups -> Eintrag nach $GROUP
chgrp -R $GROUP /home/groups/$GROUP
chmod -R 770 /home/groups/$GROUP
# Ende der Schleife

Allerdings hab ich reichlich wenig Plan von der Bash-Programmierung. Vielleicht könnt ihr mir helfen. Vor allem auch, wo ich das Skript dann einbinde, das es beim Login ausgrführt wird.

Basti

[gms]

Das Script

Code: Alles auswählen

#!/bin/sh
for dir in /home/group/*; do 
  [ -d "$dir" ] || continue
  group=`basename "$dir"`
  echo chgrp -R "$group" "$dir"
  chmod -R 770 "$dir"
 done

Willst du das Script wirklich bei jedem Login aufrufen ? Genügt nicht ein Cronjob ?

[bbastix]

Wow! Danke! Rasselt die Schleife nicht in die Einträge "." und ".." rein?

Willst du das Script wirklich bei jedem Login aufrufen ? Genügt nicht ein Cronjob ?

Es wäre gut, wirklich bei jedem Einloggen die Rechte einzustellen. Viele Daten weden das nicht sein, so dass die Verzögerung wahrscheinlich unmerklich wäre. Die Ausgabe werde ich rausnehmen.

Wo binde ich das Skript dann ein? In den .bashrc?

Basti

[gms]

Rasselt die Schleife nicht in die Einträge "." und ".." rein?

nein

Wo binde ich das Skript dann ein? In den .bashrc?

Direkt in der .bashrc wirst du Probleme mit den Rechten bekommen, das Script sollte schon als root ausgeführt werden.
Wenn du also darauf bestehtst, daß das bei jedem Login aufgerufen werden soll, würde ich dir einmal empfehlen dieses Script irgendwo abzulegen (nur für root ausführbar und schreibbar). Danach über sudo, allen deinen Gruppenmitgliedern die Ausführung dieses Scripts gestatten und dann das Kommando "sudo <scriptname>" irgendwo (/etc/profile,...) einzubinden.

[bbastix]

An sudo hatte ich auch gedacht, aber letzlich kann ich doch auch einfach das SUID-Bit setzen oder übersehe ich da was? Es werden ja keine Parameter übergeben und das Skript kann von mir aus so oft laufen, wie es will.

> und dann das Kommando "sudo <scriptname>" irgendwo (/etc/profile,...) einzubinden.

"irgendwo" is doof! *g*
Ich gehe davon aus, dass sich die Benutzer nur über KDM nach KDE einloggen - wäre also auch Möglich einen Link nach ~/.kde/Autostart zu legen. Anders wäre es mir aber natürlich lieber.

Basti

[Fentanyl]

Am einfachsten und ungefährlichsten ist es, das script via cron auszuführen. Sowohl sudo als auch setuid bieten potentielle Angriffsmöglichkeiten. Ich verstehe auch immernoch nicht, warum bei jedem login die Rechte neu gesetzt werden müssen. Erstens kann man das ausnutzen (flooding, je nachdem wie umfangreich deine Verzeichnishierarchie ist) und zweitens sollte eine kontrolle pro 15 min doch eigentlich schicken, oder?

Du kannst es zwar in die /etc/profile eintragen, hilft aber nichts, da es mit den rechten des einloggenden benutzers ausgeführt werden wird. Gleiches gilt natürlich auch für deine kde-Methode.

MfG; Fenta

[bbastix]

Hi.

> Sowohl sudo als auch setuid bieten potentielle Angriffsmöglichkeiten.

Ich kenn mich mit der Shell-Programmierung eben ganicht aus. Sag doch mal, wie das abgedruckte Skript mit setuid-Bit für einem Angriff benutzt werden könnte. Links werden doch so nicht verfolgt, oder?

> Ich verstehe auch immernoch nicht, warum bei jedem login die Rechte neu gesetzt werden
> müssen. Erstens kann man das ausnutzen (flooding, je nachdem wie umfangreich deine
> Verzeichnishierarchie ist) und zweitens sollte eine kontrolle pro 15 min doch eigentlich
> schicken, oder?

Wahrscheinlich wird es nur ein solches Gruppenverzeichnis und vielleicht zwei, drei Benutzer geben, die sich - vorm Rechner sitzend - einloggen und so sicherlich kein Interesse haben, das System heiß laufen zu lassen - was sie in dem Fall mit einer fork-bomb auch etwas effektiver angehen könnten, oder lieg ich da falsch?

Der Grund bzw. die Idee ist einfach, dass da absolte Linux-Neulinge vorm Rechner hocken. Die Gefahr, dass jemand also die Gruppe ener Dateiändert ist ohnehin eigentlich kaum da. Nur wenn doch, dann hab ichkeinen Bock drauf, dass sich jemand anmeldet ud eine Datei nicht lesen kann, sich dann wundert und das mit dem Kollegen bespricht und 10 Minuten später gehts dann plötzlich - wie von Zauberhand. Da ist es doch allemal eleganter, das einfach beim einloggen zu erledigen, denn das Problem tritt ja frühestens auf, wenn sih jemand anderes einloggt als der, der es verursacht hat.

Dagegen würde natürlich sprechen, was immer es da an Sicherheitsproblemen geben könnte. Ich bin allerdings kein Freund von "setuid ist Böse", wenn es tatsächlich keine Angriffsmöglichkeit gibt. Aber da schau ich einfach nicht tief genug rein.

Freu mich also über weitere Beiträge - und, vielen Dank - macht echt Spaß hier...

Basti

[lochkarte]

Sag doch mal, wie das abgedruckte Skript mit setuid-Bit für einem Angriff benutzt werden könnte.

Bei einem Script bewirkt das setuid-bit genau gar nichts.

[bbastix]

Jetzt bin ich verwirrt...

[gms]

naja, das Programm das ausgeführt wird ist ja die Shell und nicht das Script, dieses wird ja nur gelesen und interpretiert. Du müßtest also der Bash das setuid-bit zukommen lassen

[Fentanyl]

Sag doch mal, wie das abgedruckte Skript mit setuid-Bit für einem Angriff benutzt werden könnte.

Bei einem Script bewirkt das setuid-bit genau gar nichts.

Ups, peinlich
Ja du hast recht, hatte das garnicht bedacht.

@bbastix: Dann nimm normalen Usern doch das Recht an chgrp, wenn sie die gruppen eh nicht ändern sollen.

MfG, Fenta

[bbastix]

...dann macht sudo <Skriptname> auch keinen Sinn, oder? Es müsste dann sudo sh <skriptname> oder heißen, oder?

> Dann nimm normalen Usern doch das Recht an chgrp, wenn sie die gruppen eh nicht
> ändern sollen.

Ich hab grad mal chown und chgrp auf 750 geändert, konnte dann aber dennoch im Konqueror per Mouseklick die Guppe ändern. Hab ich was übersehen?

Basti

[gms]

...dann macht sudo <Skriptname> auch keinen Sinn, oder? Es müsste dann sudo sh <skriptname> oder heißen, oder?

doch sudo macht Sinn, das Script wird im entsprechendem Environment gestartet. Verwende aber "sudo <scriptname"

Ich hab grad mal chown und chgrp auf 750 geändert, konnte dann aber dennoch im Konqueror per Mouseklick die Guppe ändern. Hab ich was übersehen?

Nein, das war einfach keine schlaue Idee, gibt ja auch Systemcall's

[Fentanyl]

Also ich hab damit bislang keine Probleme, hab hier aber ehrlichgesagt auch alles sehr restriktiv.

edit: muss leider zugeben, dass man mit bestimmten Usern doch Zugriff hat (bislang nicht ausgiebig getestet). Vielleicht hat ja jemand einen besseren Vorschlag, um das ändern von Gruppen für normale User zu unterbinden...

MfG; Fenta