Vraag Hoe Linux-machtigingen in te stellen voor de WWW-map?


Bijgewerkte samenvatting

De / var / www-directory is eigendom van root:root wat betekent dat niemand het kan gebruiken en het is volkomen nutteloos. Omdat we allemaal een webserver willen die echt werkt (en niemand zich zou moeten aanmelden als "root"), moeten we dit oplossen.

Slechts twee entiteiten hebben toegang nodig.

  1. PHP / Perl / Ruby / Python ze hebben allemaal toegang tot de mappen en bestanden nodig omdat ze er veel van maken (d.w.z. /uploads/). Deze scripttalen zouden onder nginx of apache moeten werken (of zelfs iets anders zoals FastCGI voor PHP).

  2. De ontwikkelaars

Hoe krijgen ze toegang? ik weet dat iemand ergens heeft dit eerder gedaan. Met echter vele miljarden websites die er zijn, zou je denken dat er meer informatie over dit onderwerp zou zijn.


Ik weet dat 777 volledige lees / schrijf / voer toestemming voor eigenaar / groep / ander is. Dus dit lijkt niet te zijn nodig zijn correct omdat het willekeurige gebruikers volledige rechten geeft.

Op welke machtigingen moet worden gebruikt /var/www zodat:

  1. Bronbeheer zoals git of svn
  2. Gebruikers in een groep zoals 'websites' (of zelfs toegevoegd aan "www-data")
  3. Servers houden van apache of lighthttpd
  4. En PHP / Perl / Ruby

kunnen daar allemaal bestanden (en mappen) lezen, maken en uitvoeren?

Als ik het goed heb, worden Ruby- en PHP-scripts niet rechtstreeks "uitgevoerd" - maar doorgegeven aan een tolk. Er is dus geen toestemming nodig voor het uitvoeren van bestanden in /var/www...? Daarom lijkt het erop dat de juiste toestemming zou zijn chmod -R 1660 wat zou maken

  1. alle bestanden die door deze vier entiteiten kunnen worden gedeeld
  2. alle bestanden niet-uitvoerbaar per ongeluk
  3. blokkeer alle anderen volledig uit de directory
  4. stel de toestemmingsmodus in op "plakkerig" voor alle toekomstige bestanden

Is dit correct?

Update 1: Ik realiseerde me net dat bestanden en mappen mogelijk andere rechten nodig hebben - ik had het over bovenstaande bestanden, dus ik weet niet zeker wat de directoryrechten zouden moeten zijn.

Update 2: De mappenstructuur van /var/www verandert drastisch omdat een van de vier bovenstaande entiteiten altijd vele niveaus diep en vaak mappen (en submappen) toevoegt (en soms verwijdert). Ze maken en verwijderen ook bestanden waarvan de andere 3 entiteiten lees- / schrijftoegang nodig hebben. Daarom moeten de machtigingen de vier bovenstaande dingen doen voor zowel bestanden als mappen. Omdat geen van hen de toestemming nodig heeft om uit te voeren (zie de vraag over robijn / php hierboven), zou ik ervan uitgaan rw-rw-r-- toestemming zou alles zijn dat nodig en volledig veilig is, omdat deze vier entiteiten worden gerund door vertrouwd personeel (zie # 2) en alle andere gebruikers op het systeem hebben alleen leestoegang.

Update 3: Dit is voor personal development-machines en privé-bedrijfsservers. Geen willekeurige "webklanten" zoals een gedeelde host.

Update 4:  Dit artikel door slicehost lijkt de beste te zijn om uit te leggen wat er nodig is om machtigingen in te stellen voor uw www-map. Ik weet echter niet zeker welke gebruiker of groep apache / nginx met PHP OF svn / git wordt uitgevoerd en hoe deze te wijzigen.

Update 5: Ik heb (denk ik) eindelijk een manier gevonden om dit allemaal te laten werken (antwoord hieronder). Ik weet echter niet of dit de juiste en VEILIGE manier is om dit te doen. Daarom ben ik een premie begonnen. De persoon die de beste methode heeft om de www-directory te beveiligen en te beheren, wint.


61
2018-03-22 01:21


oorsprong




antwoorden:


Na meer onderzoek lijkt het alsof een andere (mogelijk betere manier) om dit te beantwoorden zou zijn om de map www zo in te stellen.

  1. sudo usermod -a -G developer user1 (voeg elke gebruiker toe aan de ontwikkelaargroep)
  2. sudo chgrp -R developer /var/www/site.com/ zodat ontwikkelaars daar kunnen werken
  3. sudo chmod -R 2774 /var/www/site.com/ zodat alleen ontwikkelaars bestanden kunnen maken / bewerken (andere / wereld kunnen lezen)
  4. sudo chgrp -R www-data /var/www/site.com/uploads zodat www-data (apache / nginx) uploads kan maken.

Sinds git wordt uitgevoerd zoals de gebruiker het noemt, en zo lang als de gebruiker zich in de "ontwikkelaar" groep bevindt, zouden ze in staat moeten zijn om mappen te maken, PHP bestanden te bewerken en de git repository te beheren.

Opmerking: In stap (3) betekent '2' in 2774 'Groep-ID instellen' voor de map. Hierdoor worden nieuwe bestanden en submappen die daarin zijn gemaakt, overgenomen van de groeps-ID van de bovenliggende map (in plaats van de primaire groep van de gebruiker). Referentie: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories 


47
2018-03-25 21:27



Ziet er redelijk uit voor mij. - wazoox
Goed. Misschien als ik dit met een paar meer mensen kan bevestigen, zal ik deze benadering gebruiken. Het lijkt het beste antwoord te zijn dat ik uit mensen heb kunnen persen. - Xeoncross
U geeft niet aan wie de eigenaar van de bestanden zou zijn. Zou je het als root achterlaten? Alleen sudoers kunnen dan je uploadmap bewerken (waarschijnlijk niet wat je van plan was). - Nic
Ja, root zou de eigenaar blijven. Omdat de groepseigenaar nu 'ontwikkelaar' is (en beschikt over wrx-rechten), kunnen alle ontwikkelaars (en apache / nginx) ook lezen. Geen behoefte aan sudo. - Xeoncross
Nog een ding om op te letten, is umask. Veel systemen hebben een standaard umask van 022, die schrijfrechten voor zowel de groep als het publiek voor nieuwe bestanden zal verwijderen. Ik vermoed dat je 002 wilt (geen schrijf voor publiek) of 007 (geen toegang voor publiek). U kunt de umask instellen in de configuratie- en / of opstartscripts van Apache voor elk proces dat toegang tot de map nodig heeft. Vergeet niet om dit toe te voegen aan / etc / profile of / etc / bashrc zodat het ook standaard is ingesteld voor uw ontwikkelaars - Mark Porter


Ik weet niet zeker of het "goed" is, maar hier is wat ik doe op mijn server:

  • / var / www bevat een map voor elke website.
  • Elke website heeft een aangewezen eigenaar, die is ingesteld als de eigenaar van alle bestanden en mappen in de directory van de website.
  • Alle gebruikers die de website onderhouden, worden in een groep voor de website geplaatst.
  • Deze groep is ingesteld als de groepseigenaar van alle bestanden en mappen in de map.
  • Alle bestanden of mappen die door de webserver moeten worden geschreven (bijv. PHP) hebben hun eigenaar gewijzigd in www-data, de gebruiker waar de apache onder valt.

Houd er rekening mee dat u de execute-bit moet hebben ingeschakeld in directory's, zodat u de inhoud kunt weergeven.


8
2018-03-22 02:52



Hoe maakt git / svn of PHP dan nieuwe mappen aan? - Xeoncross
PHP wordt uitgevoerd in dezelfde gebruikerscontext als de webserver, zodat het bestanden en mappen kan maken in elke directory die eigendom is van de webserver. Er zijn over het algemeen maar een paar mappen zoals deze (/ uploads / bijvoorbeeld). Ik ben niet zeker van git / svn. Kun je ze toevoegen aan het groepsaccount dat de website beheert? - Nic
blijkbaar loopt git als de gebruiker die het draait - net als elke andere tool. - Xeoncross
Voeg vervolgens de git-gebruiker toe aan de apache-groep en geef de mapgroep schrijfrechten. - David Rickman
Ik zei net, git heeft geen gebruiker - het draait zoals de huidige gebruiker het gebruikt. - Xeoncross


Na meer onderzoek te hebben gedaan lijkt het erop dat git / svn HULPMIDDELEN zijn GEEN probleem omdat ze worden uitgevoerd zoals de gebruiker ze gebruikt. (De git / svn-daemons zijn echter een andere zaak!) Alles wat ik met git heb gemaakt / gekloond had mijn permissies en de git-tool was vermeld in /usr/bin wat bij dit proefschrift past.

Git-machtigingen zijn opgelost.

Gebruikersrechten lijken oplosbaar te zijn door alle gebruikers die toegang moeten hebben tot de www-map toe te voegen aan de www-data groepeer apache (en nginx) als.

Dus het lijkt erop dat één antwoord op deze vraag gaat als volgt:

Standaard /var/www is eigendom van root:root en niemand kan daar bestanden toevoegen of wijzigen.

1) Wijzig de groepseigenaar

Eerst moeten we de www-directorygroep wijzigen die eigendom moet zijn van de "www-data" in plaats van de "root" -groep

sudo chgrp -R www-data /var/www

2) Voeg gebruikers toe aan www-data

Vervolgens moeten we de huidige gebruiker (en iemand anders) aan de www-gegevensgroep toevoegen

sudo usermod -a -G www-data demousername

3) CHMOD www-directory

Wijzig de machtigingen zodat ALLEEN de eigenaar (root) en alle gebruikers in de groep "www-data" rwx (lees / schrijf / uitvoer) bestanden en mappen (niemand anders zou er zelfs maar toegang toe moeten hebben).

sudo chmod -R 2770 /var/www

Nu zullen alle bestanden en mappen gecreëerd door elke gebruiker die toegang heeft (dat wil zeggen in de "www-data" groep) leesbaar / beschrijfbaar zijn door apache en vandaar php.

Is dit correct? Hoe zit het met de bestanden die PHP / Ruby maken - kunnen de gebruikers van www-data er toegang toe krijgen?


6
2018-03-24 03:15



Ik vind het niet leuk om alle webbestanden beschrijfbaar te hebben door PHP, het verhoogt je mogelijke blootstelling als er een scriptkwetsbaarheid is. - Nic
Ok, nou ik weet dat ik PHP gebruik om veel van te maken tekst, tar, log en afbeelding bestanden (plus mappen), dus ik ging ervan uit dat alles beschrijfbaar moest zijn. Misschien moeten jouw rechten en PHP echter alleen VERANDER BESTANDEN DIE HET MAAKT wat onschadelijk zou zijn omdat 99% van alle PHP-apps nooit scriptbestanden maakt. De andere keuze lijkt te zijn om alleen bepaalde mappen PHP-schrijftoegang (/ uploads /) toe te staan, wat niet gebeurt omdat PHP dan nog steeds kan worden gebruikt om daar iets slechts te creëren. Om het even welke ideeën? - Xeoncross
Probeer script en gegevens gescheiden te houden. Zelfs als een aanvaller erin slaagt iets in / uploads / te plaatsen, zou het niet uitvoerbaar moeten zijn. Beveiliging in lagen is de sleutel. - Nic


Kleverigheid is geen overerving van machtigingen. Kleverigheid in een directory betekent dat alleen de eigenaar van een bestand, of de eigenaar van de directory, dat bestand in de directory kan hernoemen of verwijderen, ondanks het feit dat de permissies anders zeggen. Dus 1777 op / tmp /.

In klassieke Unix is ​​er geen overerving van machtigingen op basis van het bestandssysteem, alleen in het umask van het huidige proces. Op * BSD of Linux met setgid in de map, wordt het groepsveld van nieuw gemaakte bestanden ingesteld op hetzelfde als dat van de bovenliggende map. Voor meer informatie moet u ACL's bekijken, met de 'standaard' ACL op mappen, die u wel over geërfde machtigingen laten beschikken.

U moet beginnen met het definiëren van:  * wat gebruikers toegang hebben tot het systeem  * wat je dreigingsmodel is

Als u bijvoorbeeld webhosting met meerdere klanten doet en niet wilt dat ze elkaars bestanden zien, dan kunt u een algemene groep "webcusts" gebruiken voor al die gebruikers en een directory-modus van 0705. Dan worden bestanden geserveerd door het webserverproces (niet in "webcusts") ziet de Andere perms en wordt toegestaan; klanten kunnen elkaars bestanden niet zien en de gebruikers kunnen rommelen met hun eigen bestanden. Dit betekent echter wel dat zodra u CGI of PHP toestaat hebben om ervoor te zorgen dat de processen als de specifieke gebruiker worden uitgevoerd (in ieder geval goede praktijken, voor meerdere gebruikers-op-één-host, voor verantwoording). Anders kunnen klanten knoeien met elkaars bestanden door een CGI te doen.

Als de runtime-gebruiker voor een website echter dezelfde is als de eigenaar van de website, dan zijn er problemen met het niet kunnen beschermen van inhoud tegen misbruikers in het geval van een beveiligingslek in het script. Dat is waar toegewijde hosts winnen, zodat u een runtime-gebruiker kunt hebben die zich onderscheidt van de eigenaar van de statische inhoud en u zich niet zoveel zorgen hoeft te maken over de interactie met andere gebruikers.


5
2018-03-22 03:37



Goed antwoord. Op MacOS X gedraagt ​​het systeem zich alsof het SGID-bit automatisch in de mappen staat. Het plakkerige bit betekent meestal dat je het bestand alleen kunt verwijderen als je het kunt schrijven. Dat wil zeggen, iedereen kan een publiekelijk beschrijfbaar bestand in / tmp verwijderen. Op MacOS X is / tmp een symlink naar een privé-directory voor de gebruiker - dus er is tenslotte geen delen. - Jonathan Leffler
Bedankt voor het antwoord, ik heb de vraag met meer informatie bijgewerkt. - Xeoncross
Jonathan: de sticky bit betekent dat alleen de eigenaar van de map, of de eigenaar van het bestand, de naam van de map kan wijzigen of de map kan verwijderen (dat wil zeggen: handelen op basis van de vermelding in de map 'bestand'). Machtigingen voor het individuele bestand komen niet in aanmerking voor deze directory-bewerkingen (rename(), unlink()), alleen voor acties op het bestand zelf (open()). Dit is het "gebruikelijke" gedrag. - Phil P


Ik geloof echt dat de beste manier om dit te doen het gebruik van Posix ACL's is. Ze zijn comfortabel om mee te werken en bieden alle functionaliteit die u nodig hebt.

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs

Hier is een handleiding voor het gebruik van ACL's. Afhankelijk van uw distributie bevat uw kernel mogelijk al ACL-ondersteuning.

http://www.cs.unc.edu/cgi-bin/howto?howto=linux-posix-acls


2
2018-03-26 10:44



+1 voor nuttige informatie over ACL's. Ik wil echter niet dat extra rommel het systeem platloopt, alleen maar om een ​​eenvoudige server met een paar ontwikkelaars te beheren. Ik ben ook niet comfortabel met het hercompileren van de kernel om ACL's te kunnen gebruiken. - Xeoncross
@Xeoncross: ACL's vatten niets op. Het zijn slechts metainformaties zoals normale bestandsrechten. Het is niet dat alles "extra" en gecompliceerd, ik geloof dat het de eenvoudigste en beste manier is om permissies te beheren in plaats van een verwarrende sticky / group / whatever oplossing. Wees niet bang, zet gewoon opnieuw aan met acl en probeer het eens! - Tie-fighter


De eigenaar van het bestand moet de persoon zijn die het bestand maakt, terwijl de groep www-gegevens moet zijn. De modus voor mappen / bestanden is dan in het algemeen 755/644. Terwijl voor mappen en bestanden de groep schrijftoegang nodig heeft, is de mod 775/664. Stel dat paddy de ontwikkelaar is. Al met al maakt dit:

chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;  
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;

1
2017-09-24 18:08





Toe te voegen aan het antwoord van @ Xeoncross, ik denk dat het goed zou zijn om machtigingen voor bestanden en mappen apart in te stellen.

sudo find /var/www -type d -exec chmod 775 {} \;  # Change permissions of directories to rwxrwxr-x
sudo find /var/www -type f -exec chmod 664 {} \;  # Change file permissions to rw-rw-r--

Hierdoor kunnen ontwikkelaars mappen aanmaken / wijzigen binnen / var / www. Dat lijkt belangrijk omdat ontwikkelaars mogelijk extra mappen moeten maken of een directory moeten verwijderen die niet langer nodig is.

Het zal ontwikkelaars ook toestaan ​​om codebestanden te maken en te wijzigen (lees HTML, PHP-bestanden en dergelijke). Maar blijft alleen-lezentoegang voor alle anderen alleen toestaan.


0
2017-12-09 05:38