Schrift
[thread]9703[/thread]

Dateibesitzer und Rechte bei Apache: Hosteurope ist doof. :-)



<< |< 1 2 >| >> 19 Einträge, 2 Seiten
cbxk1xg
 2004-07-02 19:44
#94789 #94789
User since
2003-10-20
496 Artikel
BenutzerIn
[default_avatar]
Hallo Freunde der Sonne,

ich habe ein etwas ungewöhnliches Problem. Ich habe bei Hosteruope ein sogenanntes Webpack. Zu diesem Webpack habe ich einen FTP-account. Wenn ich nun via FTP eine Datei hochlade, wird der Besitzer der Datei als "ftp123" mit der Gruppe "FTP" angegeben. Da die Seite aber mit einem CMS administriert wird, möchte ich diese hochgeladenen HTML oder Textdateien auch dort aufrufen und bearbeiten. Dummerweise gehören aber Dateien, die man mit CGI-Scripts erstellt, oder ändert, immer dem User "nobody" in der Gruppe "nobody".

Das führt nun dazu, dass man Dateien, die man per FTP hochgeladen hat, nicht mehr editieren kann. Wenn man einen Schreibzugriff auf die Datei macht, wird dieser einfach ignoriert.

Hosteuope versucht ständig mir das als Feature und nicht als BUG zu verkaufen. Komisch nur, dass das bei 1und1 und auch anderen Providern als BUG gesehen wird.

Hat jemand einen Lösungsansatz dafür?
renee
 2004-07-02 20:09
#94790 #94790
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Kannst Du auf den Ordner die Rechte 777 setzen??

Wenn ja, dann schreib Dir einfach schnell ein Skript mit Net::FTP und lade gleich alles mit dem Skript hoch. Dann gehören die Dateien dem user "nobody"...

Wenn nein, könnte es schwierig werden. Ich kenn Hosteurope und die exakte Situation dort nicht...
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
ptk
 2004-07-02 20:28
#94791 #94791
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
Folgendes koennte man als Workaround verwenden (ungetestet):
Code: (dl )
1
2
3
4
5
6
7
use File::Copy qw(cp);
open(my $fh, ">upgeloadete_datei") or do {
# ups, keine Schreibrechte
cp "upgeloadete_datei", "upgeloadete_datei~";
unlink "upgeloadete_datei";
rename "upgeloadete_datei~", "upgeloadete_datei";
};

Das geht nur unter der Annahme, dass Schreibrechte sowohl fuer nobody als auch ftp123 fuer das uebergeordnete Verzeichnis existieren und das sticky-Bit nicht gesetzt ist.
cbxk1xg
 2004-07-03 01:04
#94792 #94792
User since
2003-10-20
496 Artikel
BenutzerIn
[default_avatar]
Danke für die Antworten. Die Variante von Renee finde ich etwas bedenklich, da unsicher. Außerdem ist mir ein richtiges FTP Programm schon noch lieber. Obwohl es als gedanklicher Ansatz nicht schlecht ist.

Die Variante von ptk scheint mir die bessere lösung zu sein. Also wenn ich das richtig verstanden habe lese ich die Datei, für die ich keine Schreibrechte habe einfach ein, lösche die Datei und schreibe einfach eine neue. Richtig?

Das klingt extrem unperformant, aber sollte funktionieren. ;-)

Ach ja, was ist sticky bit?

Danke!\n\n

<!--EDIT|cbxk1xg|1088802336-->
[E|B]
 2004-07-03 01:32
#94793 #94793
User since
2003-08-08
2561 Artikel
HausmeisterIn
[Homepage] [default_avatar]
[quote=cbxk1xg,02.07.2004, 23:04]Ach ja, was ist sticky bit?[/quote]
Sticky Bit, zuweilen auch t-Rechte genannt, können auf Executables und Directories angewendet werden. Bei Executables bewirken Sie, dass sie nur einmal von der Platte geladen werden müssen, was einen Performanceschub bringt. Wird heute eher selten noch genutzt. (z.B. -rwxrwxrwxt)
Bei Directories wird es häufig aus folgendem Grund benutzt: Böswillige Benutzer könnten bei 777 einfach Dateien löschen; Sticky Bit verhindert nun ds Löschen einer solchen Datei -- Vorraussetzung zum Löschen ist dann, dass die effective uid dem Benutzer angehört.
Gruß, Erik!

s))91\&\/\^z->sub{}\(\@new\)=>69\&\/\^z->sub{}\(\@new\)=>124\&\/\^z->sub{}\(\@new\)=>);
$_.=qq~66\&\/\^z->sub{}\(\@new\)=>93~;for(@_=split(/\&\/\^z->sub{}\(\@new\)=>/)){print chr;}

It's not a bug, it's a feature! - [CGI-World.de]
renee
 2004-07-03 01:40
#94794 #94794
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Mit ein wenig (mehr) Aufwand ist das nicht so unsicher! Wenn man das überschnell machen will, dann wird es schon unsicher, aber an Deiner Stelle würde ich auch ptk's Variante benutzen...

Dort wird mit open geprüft, ob Schreibrechte bestehen (könnte man aber auch mit if(-w $filename) überprüfen). Wenn dies der Fall ist, passiert gar nichts, wenn nicht, dann wird die Datei erst kopiert (dadurch hat sie den Besitzer nobody), dann wird die ursprüngliche Datei gelöscht (Frage @ptk: geht dass denn, wenn man keine Schreibrechte hat??) und zum Schluss wird die kopierte Datei in den alten Namen umbenannt...
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
Dubu
 2004-07-03 02:57
#94795 #94795
User since
2003-08-04
2145 Artikel
ModeratorIn + EditorIn

user image
[quote=renee,02.07.2004, 23:40](Frage @ptk: geht dass denn, wenn man keine Schreibrechte hat??)[/quote]
Wenn man Schreibrechte fuer ein Verzeichnis hat, kann man jede Datei darin loeschen, auch welche, die anderen gehoeren. (Ausser eben, das o.g. sticky bit fuer das Verzeichnis ist gesetzt.)\n\n

<!--EDIT|Dubu|1088809114-->
renee
 2004-07-03 09:50
#94796 #94796
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Dann kommt doch normalerweise eine Frage nach dem Motto "Datei wirklich löschen?"...

Zu Hause habe ich leider kein Linux, aber wenn ich auf der Arbeit vom User nobody erstellte Dateien löschen will (Ich habe in dem Ordner Schreibrechte, aber nicht auf die Datei), dann kommt diese Frage...
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
cbxk1xg
 2004-07-03 14:37
#94797 #94797
User since
2003-10-20
496 Artikel
BenutzerIn
[default_avatar]
Also ich habe herrausgefunden, dass ich Dateien absurderweise einfach so mit unlink löschen, aber nicht ändern kann. Ich verstehe nicht was sich diese geistigen Vegetarier dabei gedacht haben! Das sticky bit scheint also nicht gesetzt worden zu sein. - Danke für die Erklärung.

Egal, ich werde mal versuchen ptk's Idee umzusetzen.
ptk
 2004-07-05 14:30
#94798 #94798
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
[quote=cbxk1xg,03.07.2004, 12:37]Also ich habe herrausgefunden, dass ich Dateien absurderweise einfach so mit unlink löschen, aber nicht ändern kann. Ich verstehe nicht was sich diese geistigen Vegetarier dabei gedacht haben![/quote]
Das ist normale Unix-Semantik. Wenn man Schreibrechte auf ein Verzeichnis hat, dann kann eben man Dateien loeschen, auch wenn sie einem nicht gehoeren (ausser der Ausnahme mit dem sticky-Bit). Da musst du dich schon bei den Unix-Erfindern beschweren!
<< |< 1 2 >| >> 19 Einträge, 2 Seiten



View all threads created 2004-07-02 19:44.