Discussion:
Dateirechte automatisch aendern
(zu alt für eine Antwort)
Jochen Lübbers
2008-05-30 08:10:34 UTC
Permalink
Hallo,

ich habe ein (NFS-)Verzeichnis "incomming", in das alle auf dem LAN
schreiben dürfen. Es dient dazu, Daten von Testsystemen einfach auf
meinem Arbeitsplatz zugänglich zu machen.

Nun hätte ich gerne, dass diese Dateien in jedem Fall wenigstens für
mich lesbar sind/werden - ohne dass ich nach dem "cp <src> <dst>" noch
ein "chmod" oder "chown" durchführen muss, auch wenn wenn die
ursprünglichen Rechte z.Bsp. so aussahen:
-rw------- 1 root root 10 2008-05-30 09:43 <src>

Mit dem Sticky-Bit für die Gruppe beim Verzeichnis erreiche ich jedoch
nur, dass die Datei dann anschließen so aussieht:
-rw------- 1 root users 10 2008-05-30 09:43 <src>

Das Sticky-Bit für den Eigentümer bewirkt (in diesem Kontext) nichts.

Da für mich Such-Maschinen leider nur Such-Maschinen und sehr viel
seltener Finde-Maschinen sind, bin ich beim gurgeln auch nicht schlauer
geworden.

Hat jemand Tipps (auch Such^wFinde-Tipps) für mich?

Gruß
Jochen

PS: (Ziel-)System ist Fedora 8
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Henning Paul
2008-05-30 08:30:49 UTC
Permalink
Post by Jochen Lübbers
ich habe ein (NFS-)Verzeichnis "incomming", in das alle auf dem LAN
schreiben dürfen. Es dient dazu, Daten von Testsystemen einfach auf
meinem Arbeitsplatz zugänglich zu machen.
Nun hätte ich gerne, dass diese Dateien in jedem Fall wenigstens für
mich lesbar sind/werden - ohne dass ich nach dem "cp <src> <dst>" noch
ein "chmod" oder "chown" durchführen muss, auch wenn wenn die
-rw------- 1 root root 10 2008-05-30 09:43 <src>
Bekanntes (konzeptionelles) Problem mit NFS. Einzige Abhilfe: Samba mit
den "CIFS Unix Extensions" benutzen.

Gruß
Henning
Jochen Lübbers
2008-05-30 08:39:56 UTC
Permalink
Post by Henning Paul
Bekanntes (konzeptionelles) Problem mit NFS. Einzige Abhilfe: Samba mit
den "CIFS Unix Extensions" benutzen.
Das habe ich (leider) nicht in der Hand. NFS wird bleiben. (Nicht alle
Testsysteme beherrschen überhaupt SMB...)

Gruß
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Helmut Springer
2008-05-30 08:42:47 UTC
Permalink
Post by Jochen Lübbers
Nun hätte ich gerne, dass diese Dateien in jedem Fall wenigstens für
mich lesbar sind/werden - ohne dass ich nach dem "cp <src> <dst>" noch
ein "chmod" oder "chown" durchführen muss, auch wenn wenn die
-rw------- 1 root root 10 2008-05-30 09:43 <src>
Alle NFS Zugriffe auf das exportierte fs auf Deine UID mappen.

man exports

all_squash
anonuid and anongid
--
MfG/Best regards
helmut springer panta rhei
Jochen Lübbers
2008-05-30 08:57:10 UTC
Permalink
Post by Helmut Springer
Alle NFS Zugriffe auf das exportierte fs auf Deine UID mappen.
man exports
all_squash
anonuid and anongid
Danke, für den Hinweis, habe ich leider auch nicht in der Hand. Es ist
eine Freigabe von einem Server für alle in der Gruppe (und man konnte
sich bislang nicht einmal dazu durchringen ein "root squash"
einzustellen).

Gruß
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Helmut Springer
2008-05-30 09:23:35 UTC
Permalink
Post by Jochen Lübbers
Danke, für den Hinweis, habe ich leider auch nicht in der Hand. Es
ist eine Freigabe von einem Server für alle in der Gruppe (und man
konnte sich bislang nicht einmal dazu durchringen ein "root
squash" einzustellen).
Dann waere es hilfreich, wenn Du die Gegebenheiten etwas genauer
spezifierst, sonst machen wir hier Ratestunde 8)
--
MfG/Best regards
helmut springer panta rhei
Jochen Lübbers
2008-05-30 09:56:04 UTC
Permalink
Post by Helmut Springer
Dann waere es hilfreich, wenn Du die Gegebenheiten etwas genauer
spezifierst, sonst machen wir hier Ratestunde 8)
War ich so ungenau? Entschuldigung, bin heute morgen etwas unter Druck.

Also:

Server:

(Irgendein Linux, hab ich *nicht* in der Hand) Stellt für unsere Gruppe
ein Verzeichnis /vol1/u über NFS zur Verfügung. Darin hat jeder ein
eigenes Userverzeichnis, das ihm (rechtemäßig) gehört.

Bei mir sieht das so aus:

drwxr-xr-x 31 luebbersj users 4096 2008-05-30 09:46 /vol1/u/luebbers


Arbeitsplatz:
Fedora 8; /vol1/u wird über autofs als NFS (bei Bedarf) gemountet.
Dort gibt es /vol1/u/luebbers/incomming, Rechte zur Zeit:

drwxrwxrwx 2 luebbersj users 4096 2008-05-30 09:46 /vol1/u/luebbers/incomming


Andere (Arbeitsplatz- und Test-) Rechner:
/vol1/u wird über autofs als NFS (bei Bedarf) gemountet.


Ich hätte nun gerne, (weil ich faul und vergesslich bin,) wenn ich z.Bsp
als root auf einem Testrechner einen Coredump bzw. /var/log/messages
nach /vol1/u/luebbers/incomming kopiere, dass ich, als Benutzer
'luebbersj' die Kopie wenigstens lesen kann.
Und zwar ohne, dass ich erst daran denken muss, ein chmod o+r nach dem
Kopieren auf die Kopie zu machen. (Letzteres vergesse ich nämlich immer
wieder...)

Deshalb hatte ich mit dem Set-GID-Bit und, da die Info-Seite zum (GNU)
chmod hier wage blieb, auch mit dem Set-UID-Bit gespielt. Allerdings mit
dem Ergebnis, dass das Set-UID-Bit nichts bewirkt, und das ein
automatisches Ändern der Gruppenzugehörigkeit mit nicht hilft, da es die
grundsätzlichen Rechte (z.Bsp. Gruppe darf Datei *nicht* lesen) gar
nicht anfasst.

Nun hatte ich gehofft, das es evtl. einen ähnlich wie das Set-GID-Bit
wirkenden Mechanismus gibt, der in die gewünschte Richtung geht.

Meine Suche (auch unter ACL) blieb allerdings erfolglos.

Am elegantesten wäre es natürlich, wenn automatisch alle Dateirechte beim
Kopiervorgang angepasst würden.

Natürlich kann ich als Würgaround einen crontab-Eintrag für root machen,
der alle paar Minuten etwas wie
"chown luebbersj:users /vol1/u/luebbers/incomming/*" und
"chmod 0500 /vol1/u/luebbers/incomming/*" macht.
Aber das wäre doch grausam.
(Mal ganz abgesehen von dem Seiteneffekt, dass eine solche Lösung den
automatischen Mount und *Umount* ad absurdum führen würde...)

Gruß und Danke an alle fürs Mitdenken und mir unter die Armegreifen
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Heike C. Zimmerer
2008-05-30 11:10:01 UTC
Permalink
Post by Jochen Lübbers
Ich hätte nun gerne, (weil ich faul und vergesslich bin,) wenn ich z.Bsp
als root auf einem Testrechner einen Coredump bzw. /var/log/messages
nach /vol1/u/luebbers/incomming kopiere, dass ich, als Benutzer
'luebbersj' die Kopie wenigstens lesen kann.
Wohl nicht ganz der Automatismus, den Du Dir wünschst, aber vielleicht
dennoch nützlich: Der Kopierbefehl, der im selben Rutsch Rechte und mehr
am Ziel setzen kann, nennt sich 'install'.
Jochen Lübbers
2008-05-30 11:43:45 UTC
Permalink
Post by Heike C. Zimmerer
Wohl nicht ganz der Automatismus, den Du Dir wünschst, aber vielleicht
dennoch nützlich: Der Kopierbefehl, der im selben Rutsch Rechte und mehr
am Ziel setzen kann, nennt sich 'install'.
Hm, ja, dass ist ein Ansatz, wenn auch tatsächlich am ganz anderen Ende,
als ich gedacht hatte. Aber dafür fragte ich ja auch hier. Manchmal
denkt man zu sehr in eine Richtung. "install" sollte auch auf der einen
UnixWare 2 Maschine, die mit im Zoo ist, existieren. :-)

Und zumeist bin ich beim Übertragen der Daten tatsächlich root...

Danke
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Helmut Springer
2008-05-30 12:33:03 UTC
Permalink
Post by Jochen Lübbers
Am elegantesten wäre es natürlich, wenn automatisch alle
Dateirechte beim Kopiervorgang angepasst würden.
Alle Rechte ist bei NFS nicht automagisch moeglich, file owner waere
am server machbar.

Wenn das broken setup am server nicht behebbar ist, duerfte ein
selbstgestricktes "copy" script auf Deinen clients fast noch das
effizienteste sein...
--
MfG/Best regards
helmut springer panta rhei
Markus Wichmann
2008-05-30 08:42:11 UTC
Permalink
Post by Jochen Lübbers
Hallo,
ich habe ein (NFS-)Verzeichnis "incomming", in das alle auf dem LAN
schreiben dürfen. Es dient dazu, Daten von Testsystemen einfach auf
meinem Arbeitsplatz zugänglich zu machen.
Nun hätte ich gerne, dass diese Dateien in jedem Fall wenigstens für
mich lesbar sind/werden - ohne dass ich nach dem "cp <src> <dst>" noch
ein "chmod" oder "chown" durchführen muss, auch wenn wenn die
-rw------- 1 root root 10 2008-05-30 09:43 <src>
Mit dem Sticky-Bit für die Gruppe beim Verzeichnis erreiche ich jedoch
-rw------- 1 root users 10 2008-05-30 09:43 <src>
Das Sticky-Bit für den Eigentümer bewirkt (in diesem Kontext) nichts.
Das heißt Set-UID-Bit und bringt bei Linux bei Verzeichnissen wirklich
nix. Zum Sticky-Bit komme ich weiter unten noch.
Post by Jochen Lübbers
Da für mich Such-Maschinen leider nur Such-Maschinen und sehr viel
seltener Finde-Maschinen sind, bin ich beim gurgeln auch nicht schlauer
geworden.
Ich kenne das Problem. In diesem Fall hätte man auch nur geholfen,
wenn du schon vorher gewusst hättest, was du suchen musst.
Post by Jochen Lübbers
Hat jemand Tipps (auch Such^wFinde-Tipps) für mich?
Ja: umask. Die stellt ein, welche Rechte bei einer neu angelegten
Datei alles _nicht_ gesetzt sind. Ja, ich weiß, völliger Quatsch
eigentlich, aber sei es drum. In deinem Fall würde ich einfach vor dem
Kopieren ein

umask 000 #jetzt dürfen alle alles machen
umask 022 #jetzt darfst du schreiben und die anderen dürfen lesen

ausführen.

In diesem Zusammenhang empfehle ich noch das Sticky-Bit für das
Verzeichnis zu setzen, damit nur die Eigentümer der Dateien dieselben
löschen dürfen. Standardmäßig dürften das nämlich alle mit
Schreibrechten im Verzeichnis:

chmod 1777 incoming
Post by Jochen Lübbers
Gruß
Jochen
PS: (Ziel-)System ist Fedora 8
HTH,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime
Jochen Lübbers
2008-05-30 09:12:16 UTC
Permalink
Post by Markus Wichmann
Das heißt Set-UID-Bit und bringt bei Linux bei Verzeichnissen wirklich
nix. Zum Sticky-Bit komme ich weiter unten noch.
Entschuldigung - mein Sprachgebrauch ist sehr nachlässig. Ich lernte
die drei Freunde einst unter dem (Sammel-)Begriff Sticky-Bit(s) kennen...
Post by Markus Wichmann
Ja: umask. Die stellt ein, welche Rechte bei einer neu angelegten
Datei alles _nicht_ gesetzt sind.
Danke, kenne ich.
Post by Markus Wichmann
Ja, ich weiß, völliger Quatsch eigentlich, aber sei es drum. In deinem
Fall würde ich einfach vor dem Kopieren ein
umask 000 #jetzt dürfen alle alles machen
umask 022 #jetzt darfst du schreiben und die anderen dürfen lesen
ausführen.
Verzeih, aber ich habe Tomaten auf den Augen. Ich kann leider nicht
erkennen, wie mir das hilft. Denn mein Problem ist, dass ich häufig
Dateien, die root:root o.ä. gehören und die nur für den Eigentümer
lesbar sind, dahin kopiere, und es dann immer aufwendig ist, wenn man
noch zusätzlich zum "cp" ein (paar) Kommandos absetzen muss.
Oder es wird ärgerlich, wenn man das nicht gleich getan hat, und nun den
Umweg über den (lokalen) root gehen muss, um die Rechte glattziehen zu
dürfen.
Post by Markus Wichmann
In diesem Zusammenhang empfehle ich noch das Sticky-Bit für das
Verzeichnis zu setzen, damit nur die Eigentümer der Dateien dieselben
löschen dürfen.
Bloß nicht. Nachdem ich sie ausgewertet habe (Statistik, Fehlermeldungen,
Coredumps, etc.) brauche ich sie nicht mehr (in diesem Verzeichnis) und
will/muss sie löschen; sonst quillt das schon nach einer fleißigen Woche
über!
Ja, ich weiß. Ist aber kein Problem. Macht höchstens mal jemand
ausversehen. Ist ein liebes LAN hier. :-)

Gruß
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Markus Wichmann
2008-05-30 12:49:16 UTC
Permalink
Post by Jochen Lübbers
Post by Markus Wichmann
Das heißt Set-UID-Bit und bringt bei Linux bei Verzeichnissen wirklich
nix. Zum Sticky-Bit komme ich weiter unten noch.
Entschuldigung - mein Sprachgebrauch ist sehr nachlässig. Ich lernte
die drei Freunde einst unter dem (Sammel-)Begriff Sticky-Bit(s) kennen...
Und ich hier nur das letzte von den dreien als Sticky-Bit, die anderen
beiden als Set-ID-Bits.
Post by Jochen Lübbers
Post by Markus Wichmann
Ja: umask. Die stellt ein, welche Rechte bei einer neu angelegten
Datei alles _nicht_ gesetzt sind.
Danke, kenne ich.
Post by Markus Wichmann
Ja, ich weiß, völliger Quatsch eigentlich, aber sei es drum. In deinem
Fall würde ich einfach vor dem Kopieren ein
umask 000 #jetzt dürfen alle alles machen
umask 022 #jetzt darfst du schreiben und die anderen dürfen lesen
ausführen.
Verzeih, aber ich habe Tomaten auf den Augen. Ich kann leider nicht
erkennen, wie mir das hilft. Denn mein Problem ist, dass ich häufig
Dateien, die root:root o.ä. gehören und die nur für den Eigentümer
lesbar sind, dahin kopiere, und es dann immer aufwendig ist, wenn man
noch zusätzlich zum "cp" ein (paar) Kommandos absetzen muss.
Ich merke gerade, dass ich mit meiner Vermutung daneben lag: cp erhält
den Modus, auch wenn man ihm sagt, es solle das nicht tun. Frage mich
nicht, wieso. Einzige Abhilfe wäre für einzelne Dateien:

cat $Quelle > $Ziel

mit der entsprechenden umask. Aber schon bei Verzeichnissen wird es
witzig, damit Dateien zu kopieren.
Post by Jochen Lübbers
Oder es wird ärgerlich, wenn man das nicht gleich getan hat, und nun den
Umweg über den (lokalen) root gehen muss, um die Rechte glattziehen zu
dürfen.
Das Problem wäre mittels ACL lösbar, dafür muss allerdings die
physische Platte (wo das ganze dann drauf kommt) mit der Option acl
gemounted sein. Wenn es überhaupt klappt, ich habe nämlich von NFS
keine große Ahnung.

Dann könntest du einfach für dieses Verzeichnis eine default-ACL
definieren, die dir Leserechte einräumt. Also so hier (als root auf
der Maschine):

setfacl -m d:u:$DEIN_USER:r-x $VERZEICHNIS

Wenn es nicht geht, dann liegt das daran, dass ACL über NFS nicht
unterstüzt wird. Wie gesagt, da habe ich keine Ahnung von.
Post by Jochen Lübbers
Post by Markus Wichmann
In diesem Zusammenhang empfehle ich noch das Sticky-Bit für das
Verzeichnis zu setzen, damit nur die Eigentümer der Dateien dieselben
löschen dürfen.
Bloß nicht. Nachdem ich sie ausgewertet habe (Statistik, Fehlermeldungen,
Coredumps, etc.) brauche ich sie nicht mehr (in diesem Verzeichnis) und
will/muss sie löschen; sonst quillt das schon nach einer fleißigen Woche
über!
Gut, ich dachte es war ein Austausch-Verzeichnis. Aber wenn du der
Endkonsument bist, wäre das tatsächlich nachteilig.
Post by Jochen Lübbers
Ja, ich weiß. Ist aber kein Problem. Macht höchstens mal jemand
ausversehen. Ist ein liebes LAN hier. :-)
Na dann ist ja gut :-)
Post by Jochen Lübbers
Gruß
Jochen
HTH,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime
Jochen Lübbers
2008-05-30 13:33:56 UTC
Permalink
Post by Markus Wichmann
Das Problem wäre mittels ACL lösbar, dafür muss allerdings die
physische Platte (wo das ganze dann drauf kommt) mit der Option acl
gemounted sein. Wenn es überhaupt klappt, ich habe nämlich von NFS
keine große Ahnung.
Dann könntest du einfach für dieses Verzeichnis eine default-ACL
definieren, die dir Leserechte einräumt. Also so hier (als root auf
setfacl -m d:u:$DEIN_USER:r-x $VERZEICHNIS
Wenn es nicht geht, dann liegt das daran, dass ACL über NFS nicht
unterstüzt wird. Wie gesagt, da habe ich keine Ahnung von.
Danke, da kann ich ja einmal experimentieren. Mal sehen, wovon ich
unseren Admin überzeugen kann...

Entschuldigt meine ACL-Unkenntnis, aber ich bin noch ohne so was groß
geworden...

Gruß (und so langsam an das Wochenende denkend, hier trübt es nämlich
gerade ein)
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Wolf Wiegand
2008-05-30 12:06:35 UTC
Permalink
Hallo,
Post by Jochen Lübbers
ich habe ein (NFS-)Verzeichnis "incomming", in das alle auf dem LAN
schreiben dürfen. Es dient dazu, Daten von Testsystemen einfach auf
meinem Arbeitsplatz zugänglich zu machen.
Nun hätte ich gerne, dass diese Dateien in jedem Fall wenigstens für
mich lesbar sind/werden - ohne dass ich nach dem "cp <src> <dst>" noch
ein "chmod" oder "chown" durchführen muss, auch wenn wenn die
Wenn ich mich nicht irre, müsste das mit ACLs zu erreichen sein. Durch
Setzen der Default-ACLs für das Verzeichnis erhalten alle neu dort
abgelegten Dateien diese ACLs.

hth,

Wolf
--
Wie unser Internet schöner wird: Folgende Ausdrücke will ich vermeiden:
"Surfen", "Onlinegemeinde", "Internet-Kids", "Flanieren in den Datennetzen",
"E-Mail-Addi" und "das sogenannte Internet". (die tageszeitung)
Jochen Lübbers
2008-06-03 10:18:53 UTC
Permalink
Post by Wolf Wiegand
Wenn ich mich nicht irre, müsste das mit ACLs zu erreichen sein. Durch
Setzen der Default-ACLs für das Verzeichnis erhalten alle neu dort
abgelegten Dateien diese ACLs.
Leider nicht ganz. Ich habe mal folgende ACLs vergeben:

$ getfacl /vol1/u/luebbersj/incomming
getfacl: Removing leading '/' from absolute path names
# file: vol1/u/luebbersj/incomming
# owner: luebbersj
# group: users
user::rwx
group::r-x
other::rwx
default:user::rwx
default:user:luebbersj:r-x
default:group::r-x
default:mask::r-x
default:other::rwx

Sieht für mich OK aus.
Wenn ich dann allerdings eine Datei hinkopiere, wird die Maske unschön
gesetzt:

$ getfacl /vol1/u/luebbersj/incomming/test_me
getfacl: Removing leading '/' from absolute path names
# file: vol1/u/luebbersj/incomming/test_me
# owner: root
# group: root
user::rw-
user:luebbersj:r-x #effective:---
group::r-x #effective:---
mask::---
other::---

Und effektiv darf ich dann doch nicht dran. :-(

Doch Danke für alle Tipps und Ratschläge. Ich überlege zur Zeit, ob ich
in /vol1/u/luebbersj/incomming ein Kopier-Script ablege, das dann statt
des normalen "cp" zu nutzen ist...

Gruß
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Henning Hucke
2008-06-03 20:45:28 UTC
Permalink
Wenn ich mich nicht irre, m=FCsste das mit ACLs zu erreichen sein. Durch
Setzen der Default-ACLs f=FCr das Verzeichnis erhalten alle neu dort
abgelegten Dateien diese ACLs.
[...]
Sieht f=FCr mich OK aus.
Wenn ich dann allerdings eine Datei hinkopiere, wird die Maske unsch=F6n
[...]
Hallo Jochen,

wenn Du einfach mal die manpage zu "cp" liest wirst Du feststellen, dass=20
dabei auch ACLs und dar=FCber hinaus auch extended attributs copiert werden=
=2E=20
Insofern ist es kein Wunder dass Deine ACLs in der konfigurierten Form=20
zerschossen werden. Wenn Du mal "touch" versuchst sollte das anders=20
aussehen (ungetestet)...
[...]
MfG Henning Hucke
--=20
Die Netiquette ist (lediglich) eine FAQ zu der Frage "Warum sind die andere=
n
so genervt von mir und nennen mich immer PLONK?". [Oliver Gassner in d=
sn]
Jochen Lübbers
2008-06-04 06:22:26 UTC
Permalink
Post by Henning Hucke
wenn Du einfach mal die manpage zu "cp" liest wirst Du feststellen,
dass dabei auch ACLs und darüber hinaus auch extended attributs
copiert werden. Insofern ist es kein Wunder dass Deine ACLs in der
konfigurierten Form zerschossen werden.
Gewundert hat mich das auch nicht (mehr). Ich habe mich allerdings zum
ersten Mal überhaupt mit ACLs auseinander gesetzt, und wollte deshalb
den Lösungsvorschlag (auch zum späteren Nachschlagen) nicht
unbeantwortet lassen.
Post by Henning Hucke
Wenn Du mal "touch" versuchst sollte das anders aussehen (ungetestet)...
Ja, da sieht es anders aus. Vielleicht sollte ich statt 'cp' besser ein
'cat «src» > «dest»' machen. ;-)

Gruß
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Helmut Waitzmann
2008-07-11 21:32:19 UTC
Permalink
Post by Henning Hucke
Post by Jochen Lübbers
Post by Wolf Wiegand
Wenn ich mich nicht irre, müsste das mit ACLs zu erreichen sein. Durch
Setzen der Default-ACLs für das Verzeichnis erhalten alle neu dort
abgelegten Dateien diese ACLs.
[...]
Sieht für mich OK aus.
Wenn ich dann allerdings eine Datei hinkopiere, wird die Maske unschön
[...]
Hallo Jochen,
wenn Du einfach mal die manpage zu "cp" liest wirst Du feststellen, dass
dabei auch ACLs und darüber hinaus auch extended attributs copiert
werden. Insofern ist es kein Wunder dass Deine ACLs in der konfigurierten
Form zerschossen werden. Wenn Du mal "touch" versuchst sollte das anders
aussehen (ungetestet)...
In meinem Manual-Page von »cp« (Ubuntu 7.10) taucht das Stichwort »ACL«
nicht auf.

Da vermute ich, dass »cp« so vorgeht: Wenn man den Parameter »-p«
(preserve permissions) nicht angibt, arbeitet »cp« einfach so:

Es gibt beim »open«-Systemaufruf als »mode«-Parameter einfach die
Permissions der Quell-Datei an. Die Zugriffsrechte auf die Kopie werden
dann -- wenn Default-ACLs vorhanden sind, durch diese, ansonsten durch
das umask des Kopierprozesses -- eingeschränkt.

Man muss also dafür sorgen, dass die Kopierquellen die benötigten Rechte
erlauben und zusätzlich entweder das umask richtig einstellen oder ACLs
verwenden.

Verhält sich das mit NFS anders?

Wenn man jedoch »cp« den Parameter »-p« mitgibt, führt »cp« nach dem
Kopieren noch ein »chmod()« durch. Dadurch wird natürlich das »mask« im
ACL zerstört.
--
Wer mir E-Mail schreiben will, stelle | When writing me e-mail, please
bitte vor meine E-Mail-Adresse meinen | precede my e-mail address with
Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <***@example.net>, (Helmut Waitzmann) ***@example.net
Jakobus Schuerz
2008-05-30 16:24:36 UTC
Permalink
Post by Jochen Lübbers
Hallo,
ich habe ein (NFS-)Verzeichnis "incomming", in das alle auf dem LAN
schreiben dürfen. Es dient dazu, Daten von Testsystemen einfach auf
meinem Arbeitsplatz zugänglich zu machen.
Nun hätte ich gerne, dass diese Dateien in jedem Fall wenigstens für
mich lesbar sind/werden - ohne dass ich nach dem "cp <src> <dst>" noch
ein "chmod" oder "chown" durchführen muss, auch wenn wenn die
-rw------- 1 root root 10 2008-05-30 09:43 <src>
Mit dem Sticky-Bit für die Gruppe beim Verzeichnis erreiche ich jedoch
-rw------- 1 root users 10 2008-05-30 09:43 <src>
Das Sticky-Bit für den Eigentümer bewirkt (in diesem Kontext) nichts.
Da für mich Such-Maschinen leider nur Such-Maschinen und sehr viel
seltener Finde-Maschinen sind, bin ich beim gurgeln auch nicht schlauer
geworden.
Hat jemand Tipps (auch Such^wFinde-Tipps) für mich?
Hast du dir schon incron angesehen?
Das ist ein daemon, dem du ähnlich wie einer crontab Verzeichnisse
angeben kannst, die er auf div. fs-Aktionen hin überwacht, und dann ein
skript ausführt.

Aber pass auf, wenn du viele Aktionen hast, könnte syslog schnell sehr
voll werden.

lg jakob
--
lg jakob
Jochen Lübbers
2008-06-02 07:03:06 UTC
Permalink
Post by Jakobus Schuerz
Hast du dir schon incron angesehen?
Nein, kannte ich bis eben nicht.
Post by Jakobus Schuerz
Das ist ein daemon, dem du ähnlich wie einer crontab Verzeichnisse
angeben kannst, die er auf div. fs-Aktionen hin überwacht, und dann
ein skript ausführt.
Klingt ja ganz gut, ich fürchte aber, dass er die Ereignisse, auf die er
reagieren soll, per Polling überwacht. Das bei einem Dateisystem, das
über automounter (autofs) nur bei Bedarf eingeklingt wird, nicht so toll.
(Dann ist nämlich immer Bedarf...)
Post by Jakobus Schuerz
Aber pass auf, wenn du viele Aktionen hast, könnte syslog schnell sehr
voll werden.
Kann man das nicht konfigurieren, was er in den syslog steckt und was
nicht? Na, mal sehen...

Danke
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"
Loading...