Wie vermeide ich sudo, wenn ich in / var / www arbeite?


173

Ich möchte aufhören, sudojedes Mal zu verwenden, wenn ich arbeite /var/www. Wie kann ich das machen? Ich möchte einfach alle meine Websites in dieses Verzeichnis stellen und mit ihnen arbeiten, ohne allzu große Schmerzen zu haben.


3
Benutzt du Apache?
Rinzwind

1
Nach dem Lesen hier kann dies auch im Berechtigungsteil helfen: askubuntu.com/questions/20105/…
Luis Alvarado

2
Eine andere Möglichkeit, Sicherheit zu erlangen, besteht darin, sudo -u www-datadie sudoersDatei weiterhin zu verwenden, sich jedoch darauf zu beschränken , nur in der Lage zu sein sudo www-data(und nicht in sudo root). Siehe serverfault.com/questions/295429/…
Simon Woodside,

Antworten:


250

Die meisten Antworten hier sind nicht aus Sicherheitsgründen verfasst. Es ist gut, das Gefühl zu haben, dass das Laufen sudojedes Mal nicht sehr klug ist. Wenn Sie einen Tippfehler machen (zum Beispiel eine einzelne Leerstelle an einer falschen Stelle: sudo rm -rf / var/www/dir Nicht ausführen! ), Können Sie Ihr System in den Papierkorb werfen.

Hinweis: Ab Apache 2.4.7 / Ubuntu 14.04 /var/wwwwurde verschoben, um /var/www/htmldie Befehle in dieser Antwort entsprechend anzupassen .

Sehen:

Schlechte Ideen:

  • chmod 777(sagarchalise) - Dies ermöglicht es jedem, der Zugriff auf Ihr System hat, in die Verzeichnisse und Dateien zu schreiben und somit dem Eindringling zu ermöglichen, jeden Code unter dem www-dataBenutzer auszuführen
  • chgrp -R www-data $HOME(cob) - Dies ermöglicht www-datadas Lesen oder Schreiben von Dateien im Home-Verzeichnis. Dies berücksichtigt nicht die Regel des geringsten Privilegs
  • chown -R $USER:$USER /var/www(kv1dr) - Sofern die Welt keine Leseberechtigung für hat /var/www, kann der Webserver, unter dem ausgeführt www-datawird, die Dateien nicht lesen (liefern) . Wenn es sich bei der Datei um ein öffentlich zugängliches einfaches HTML-Dokument handelt, ist es möglicherweise kein Problem, wenn die Welt die Datei lesen kann. Handelt es sich bei der Datei jedoch um eine PHP-Datei mit Kennwörtern, ist dies der Fall.

HINWEIS : In den folgenden Lösungen habe ich www-dataSchreibrechte gewährt . Es /usr/share/doc/base-passwd/users-and-groups.txt.gzheißt jedoch:

www-daten

Einige Webserver werden als WWW-Daten ausgeführt. Webinhalte sollten nicht im Besitz dieses Benutzers sein, da sonst ein kompromittierter Webserver eine Website neu schreiben kann. Von Webservern geschriebene Daten gehören www-data.

Gewähren Sie der Gruppe nach Möglichkeit keine Schreibrechte www-data. www-dataEs muss nur in der Lage sein, die Dateien zu lesen , damit der Webserver sie bereitstellen kann. Der einzige Fall, in dem www-dataSchreibberechtigungen erforderlich sind, betrifft Verzeichnisse, in denen Uploads und andere zu schreibende Speicherorte gespeichert sind.

Lösung 1

Fügen Sie sich der www-dataGruppe hinzu und setzen Sie das setgid-Bit im /var/wwwVerzeichnis so, dass alle neu erstellten Dateien auch diese Gruppe erben.

sudo gpasswd -a "$USER" www-data

Korrigieren Sie zuvor erstellte Dateien (vorausgesetzt, Sie sind der einzige Benutzer von /var/www):

sudo chown -R "$USER":www-data /var/www
find /var/www -type f -exec chmod 0660 {} \;
sudo find /var/www -type d -exec chmod 2770 {} \;

(Noch sicherer: Verwenden Sie 640oder 2750und manuell chmod g+w file-or-dir, die vom Webserver beschreibbar sein müssen.)

Lösung 2

Erstellen Sie für jedes Projekt einen Symlink zu Ihrem Home-Verzeichnis. Angenommen, Ihr Projekt befindet sich in ~/projects/foound Sie möchten, dass es sich in befindet /var/www/foo, führen Sie Folgendes aus:

sudo ln -sT ~/projects/foo /var/www/foo

Wenn in Ihrem Ausgangsverzeichnis other(aus Sicherheitsgründen) kein Ausführungsbit (absteigend) gesetzt ist , ändern Sie die Gruppe in www-data, setzen Sie jedoch nur das Ausführungsbit (kein Lesen / Schreiben). Gehen Sie für den ~/projectsOrdner genauso vor, da er möglicherweise andere Projekte als www enthält. (Dies ist nicht erforderlich, sudowenn Sie Ihren Benutzer zuvor zur www-dataGruppe hinzugefügt haben .)

sudo chgrp www-data ~ ~/projects
chmod 710 ~ ~/projects

Setzen Sie die Gruppe www-dataauf Ein ~/projects/foound erlauben Sie dem Webserver, Dateien und Dateien + Verzeichnisse zu lesen und zu schreiben und in Verzeichnisse zu gelangen:

sudo chgrp www-data ~/projects/foo
find ~/projects/foo -type f -exec chmod 660 {} \;
find ~/projects/foo -type d -exec chmod 2770 {} \;

Noch sicherer: Verwenden Sie standardmäßig 640 und 2750 und manuell chmod-Dateien und -Verzeichnisse, die vom Webserver-Benutzer beschreibbar sein müssen. Das setgid-Bit sollte nur hinzugefügt werden, wenn ~/projects/foodie Gruppe auf jede neu erstellte Datei zugreifen soll .

Von nun an können Sie auf Ihre Site unter zugreifen http://localhost/foound Ihre Projektdateien in bearbeiten ~/projects/foo.

Siehe auch


Was halten Sie von einer WWW-Sitzung in einem Terminal sudo su www-data? Kombiniert mit einer andersfarbigen Eingabeaufforderung, um klarer zu machen, dass es sich um die Shell eines anderen Benutzers handelt, und einer Richtlinie, die immer das entsprechende xterm auf - zum Beispiel - den virtuellen Desktop 4 legt, damit Sie sich daran gewöhnen, daran zu gewöhnen Verwirrung vermeiden?
Benutzer unbekannt

@user unbekannt: wenn du alles im terminal gut machst hast du eine klare trennung zwischen benutzerkonten. Aber es wird nicht funktionieren, wenn Sie ein GUI-Programm wie verwenden gedit. Ich habe nie untersucht, ob das Ausführen eines GUI-Programms unter einem anderen Benutzer in der aktuellen Sitzung sicher ist oder nicht. Dies wäre eine interessante Frage.
Lekensteyn

1
@imaginaryRobots: Wenn ich für jede Frage unterschiedliche Lösungen posten würde, wäre Askubuntu voller Antworten aus drei Zeilen. Ich werde es so lassen, wie es ist, es sei denn, Sie können mich überzeugen, es zu teilen.
Lekensteyn

1
@berbt setfacl -d u::rwX,g::rX /var/wwwhat den lustigen Effekt, dass der Standardmodus 0750 (oder 0640) wird, auch wenn die umask Null ist. Es mag eine gute Idee sein, wenn Sie Dateien vermeiden möchten, auf die /var/wwwvon der Welt aus nicht zugegriffen werden kann, sie jedoch nicht benötigen.
Lekensteyn

1
Gibt es ein Problem beim Umkehren des Prozesses in Lösung 1? Damit meine ich, /var/www/app01hat Besitz app01:app01und dann wird der www-data Benutzer der app01 Gruppe hinzugefügt ? Oder wird das etwas kaputt machen?
Jack_Hu

9

Anstatt meine Websites in / var / www zu speichern, platziere ich dort Links zu den Websites, die sich in meinem privaten Ordner befinden. Ich kann meine Websites frei bearbeiten oder Seiten hinzufügen. Wenn ich mit Änderungen zufrieden bin, gehe ich per FTP zu einem Hosting-Unternehmen, wo mein Domain-Name verlinkt ist.


Das ist eine vernünftige Idee.
Thomasrutter

7

Wenn Sie / var / www für seine Gruppe schreibbar machen und sich der Gruppe hinzufügen, müssen Sie sudo nicht verwenden, während Sie noch ziemlich sicher sind. Versuche dies:

sudo adduser <username> www-data
sudo chown -R www-data:www-data /var/www
sudo chmod -R g+rw /var/www

Sie sollten dann problemlos /var/www/Dateien bearbeiten können.

In der ersten Zeile werden Sie der www-dataGruppe hinzugefügt, in der zweiten Zeile werden alle Dateien mit fehlerhaftem Besitz gelöscht, und in der dritten Zeile werden alle Benutzer, die Mitglieder der www-dataGruppe sind, zum Lesen und Schreiben aller Dateien aufgefordert /var/www.


4
Dies ist eine sehr schlechte Idee für die Sicherheit und dieser Hinweis sollte aus Gründen, die in anderen Antworten erläutert werden, nicht befolgt werden. www-data soll eine nicht privilegierte Gruppe ohne Schreibzugriff sein.
Thomasrutter

5

Nicht

  • Setzen Sie die Dateiberechtigungen nicht auf 777 (schreibgeschützt).

    Dies ist eine erhebliche Sicherheitslücke, insbesondere wenn Sie serverseitiges Scripting wie PHP aktivieren. Unprivilegierte Prozesse sollten nicht in der Lage sein, in Dateien zu schreiben, die sich auf die Website auswirken, oder bei Verwendung von serverseitigem Scripting beliebigen Code auszuführen.

  • Fügen Sie sich nicht als Mitglied der Gruppe www-data hinzu und erteilen Sie ihr Schreibrechte

    Der Zweck dieser Gruppe besteht darin, dass es sich um eine nicht privilegierte Gruppe handelt, als die die Serverprozesse ausgeführt werden. Sie sollten aus den gleichen Gründen wie oben nur Lesezugriff auf die Website-Dateien haben, sofern dies möglich ist.

  • Ändern Sie nicht die Berechtigungen der Apache-Prozesse

    Die untergeordneten Apache-Prozesse www-datawerden standardmäßig als Benutzer und Gruppe ausgeführt. Dies sollte nicht geändert werden. Dies ist nur eine Möglichkeit, dem Dateisystem keine Schreibberechtigung zu erteilen.

    Unter bestimmten Umständen möchten Sie, dass Ihre serverseitigen Skripts in die Lage versetzt werden, in Dateien zu schreiben. In diesem Fall sollten nur diese Dateien von beschreibbar gemacht werden, www-dataund es muss darauf geachtet werden, dass die Sicherheit gewährleistet ist.

DOS

  • Stellen Sie die Dateien so ein, dass sie Ihnen gehören

    Wenn Sie die einzige oder die übliche Person sind, die bestimmte Dateien auf der Website ändert, ist es absolut sinnvoll, nur den Besitz dieser Dateien zu übernehmen. Setzen Sie ihren Besitzer auf <your username>.

    Sie müssen die Serverberechtigungen dafür nicht ändern, da der Server auch dann weiterhin schreibgeschützt ist, wenn die Dateien Ihnen gehören.

  • Wählen Sie einen vernünftigen Speicherort für die Dateien (mit DocumentRoot )

    Wenn /var/wwwdies keinen Sinn ergibt, können Sie sie gerne an einer anderen Stelle platzieren. Wenn sie spezifisch für Ihre eigene Entwicklung oder Ihr Testen sind, können Sie sie in Ihrem Home-Verzeichnis ablegen. Oder Sie können einige Verzeichnisse in einrichten /srv.

  • Wenn Sie Gruppenschreibzugriff gewähren möchten, erstellen Sie zu diesem Zweck eine neue Gruppe

    Verwenden Sie eine Systemgruppe nicht erneut, da diese aus Sicherheitsgründen in der Regel den Zugriff haben, den sie derzeit haben, und nicht mehr.


5

So einfach ist das. Sie müssen weder Apache 'UserDir' aktivieren (nicht empfohlen) noch mit 'www-data'-Gruppen in Verlegenheit bringen (Apache-Gruppe bei Fedora)

Erstellen Sie einfach Ihr Projektverzeichnis /var/www/html

cd /var/www/html
sudo mkdir my_project

Dann geben Sie einfach das Projektverzeichnis an Ihren Benutzer weiter.

sudo chown your_username my_project

Jetzt können Sie als normaler Benutzer mit einem beliebigen Editor, einer IDE Ihrer Wahl, an Ihrem Projektordner arbeiten. Keine mehr sudos :)


1
+1 Das ist, was ich tue: Ändern Sie den Besitz nicht von sich /var/wwwselbst, sondern von Unterverzeichnissen.
Fkraiem

2

chmod in / var auf www, um dem Besitzer Zugriff zu gewähren, und chown, um sicherzustellen, dass Sie es besitzen. Wahrscheinlich eine blöde Idee, aber es würde definitiv funktionieren.


2
Keine dumme Idee, aus Sicherheitsgründen eine vernünftige. Hinweis: Sie müssen (und sollten) die Berechtigungen von /var, just /var/wwwund / oder dessen Inhalt nicht ändern .
Thomasrutter

1

Sie können eine www-Sitzung in einem Terminal durch starten

sudo su www-data

Kombiniert mit einer andersfarbigen Eingabeaufforderung *, um klarer zu machen, dass es sich um die Shell eines anderen Benutzers handelt, und einer Richtlinie, die immer das entsprechende xterm (und den entsprechenden Editor usw.) auf dem virtuellen Desktop 4 installiert, damit man gewöhnt sich daran, um Verwirrung zu vermeiden.

*) Erstellen Sie für eine andersfarbige Eingabeaufforderung mit einem anderen Zeichen eine Datei / etc / prompt wie folgt:

# PROMPTING
#       When  executing  interactively, bash displays the primary prompt PS1 when it is ready to read a command, and the sec-
#       ondary prompt PS2 when it needs more input to complete a command.  Bash allows these prompt strings to be  customized
#       by inserting a number of backslash-escaped special characters that are decoded as follows:
#              \a     an ASCII bell character (07)
#              \d     the date in "Weekday Month Date" format (e.g., "Tue May 26")
#              \D{format}
#                     the  format is passed to strftime(3) and the result is inserted into the prompt string; an empty format
#                     results in a locale-specific time representation.  The braces are required
#              \e     an ASCII escape character (033)
#              \h     the hostname up to the first `.'
#              \H     the hostname
#              \j     the number of jobs currently managed by the shell
#              \l     the basename of the shell's terminal device name
#              \n     newline
#              \r     carriage return
#              \s     the name of the shell, the basename of $0 (the portion following the final slash)
#              \t     the current time in 24-hour HH:MM:SS format
#              \T     the current time in 12-hour HH:MM:SS format
#              \@     the current time in 12-hour am/pm format
#              \A     the current time in 24-hour HH:MM format
#              \u     the username of the current user
#              \v     the version of bash (e.g., 2.00)
#              \V     the release of bash, version + patchelvel (e.g., 2.00.0)
#              \w     the current working directory
#              \W     the basename of the current working directory
#              \!     the history number of this command
#              \#     the command number of this command
#              \$     if the effective UID is 0, a #, otherwise a $
#              \nnn   the character corresponding to the octal number nnn
#              \\     a backslash
#              \[     begin a sequence of non-printing characters, which could be used to embed a terminal  control  sequence
#                     into the prompt
#              \]     end a sequence of non-printing characters
#
#       The  command  number and the history number are usually different: the history number of a command is its position in
#       the history list, which may include commands restored from the history file (see HISTORY below),  while  the  command
#       number  is  the  position in the sequence of commands executed during the current shell session.  After the string is
#
# colors:
# \[...\]   wird benötigt, damit die shell weiß, daß hier kein printable output ist, und die Umbrüche richtig plaziert.
#
# ANSI COLORS
CRE="\[
[K\]"
NORMAL="\[[0;39m\]"
# RED: Failure or error message
RED="\[[1;31m\]"
# GREEN: Success message
GREEN="\[[1;32m\]"
# YELLOW: Descriptions
YELLOW="\[[1;33m\]"
# BLUE: System messages
BLUE="\[[1;34m\]"
# MAGENTA: Found devices or drivers
MAGENTA="\[[1;35m\]"
# CYAN: Questions
CYAN="\[[1;36m\]"
# BOLD WHITE: Hint
WHITE="\[[1;37m\]"
#
# default:
# postgres, oracle, www-data
#
# PS1=$BLUE"machine]->"$NORMAL\\w"$BLUE ø $NORMAL"
PS1=$BLUE"machine]:"$NORMAL\\w"$BLUE > $NORMAL"
#
# root, stefan:
#
case "$UID" in
    '0')
        PS1=$RED"machine:"$NORMAL\\w"$RED # $NORMAL"
    ;;
    '1000')
    PS1=$GREEN"machine:"$BLUE\\w$YELLOW" > "$NORMAL
    ;;
#    default)
#    ;;
esac

und es /etc/bash.bashrczum Beispiel von Quelle .

Als zusätzliches Hilfsmittel zur Unterscheidung können Sie Ihre Dateien jederzeit mit einem Alias ​​"Bearbeiten" oder einem Symlink bearbeiten, der abhängig von Ihrer Identität (Taylor- / WWW-Daten) entweder auf gedit oder Mousepad, vim oder pico verweist. Oder Sie können verschiedene Editorprofile verwenden. Zumindest in gedit können Sie Ihre Einstellungen auf schwarzen Text auf weißem Grund oder weißen Text auf schwarzem Grund festlegen.

Ich habe nur eine solche Richtlinie für die Arbeit als Root, daher bin ich mir nicht sicher, wie gut sie für die Arbeit mit WWW-Daten geeignet ist. In Kombination mit SSH-Sitzungen mit verschiedenen Hosts, die ihre eigenen Eingabeaufforderungen haben, hat es mich nicht davon abgehalten, manchmal falsch zu liegen, aber wenn es passiert, merke ich schnell, was falsch ist, und es passiert selten.

hinweis: Das prompt-script ist teilweise eine kopie der manpage von bash.


Dies funktioniert und beeinträchtigt die Sicherheit nicht (wenn es mit Bedacht verwendet wird), ist jedoch möglicherweise nicht die einfachste Lösung. Es ist jedoch eine gültige Lösung für einige Leute.
Thomasrutter
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.