Vraag Wat is de beste manier om toestemmingen voor de gebruikersww-gegevens van Apache 2 in / var / www te behandelen?


Heeft iemand een leuke oplossing gekregen voor het verwerken van bestanden in /var/www? We gebruiken op naam gebaseerde virtuele hosts en de Apache 2-gebruiker is dat www-data.

We hebben twee vaste gebruikers en root. Dus als je met bestanden knoeit /var/www, in plaats van dat je ...

chown -R www-data:www-data

... de hele tijd, wat is een goede manier om hiermee om te gaan?

Aanvullende vraag: hoe hard ga je dan over toestemmingen?

Deze is altijd een probleem geweest in samenwerkende ontwikkelomgevingen.


211
2018-05-11 05:13


oorsprong


Zie ook: Wat zijn de beste Linux-machtigingen voor mijn website? - Zoredache


antwoorden:


Poging om uit te breiden op @ Zoredache's antwoord, terwijl ik dit zelf probeer:

  • Maak een nieuwe groep (www-pub) en voeg de gebruikers toe aan die groep

    groupadd www-pub

    usermod -a -G www-pub usera  ## moet -a gebruiken om aan bestaande groepen toe te voegen

    usermod -a -G www-pub userb

    groups usera  ## weergave groepen voor gebruiker

  • Verander het eigendom van alles onder / var / www in root: www-pub

    chown -R root:www-pub /var/www  ## -R voor recursief

  • Wijzig de machtigingen van alle mappen in 2775

    chmod 2775 /var/www  ## 2 = stel groeps-ID in, 7 = rwx voor eigenaar (root), 7 = rwx voor groep (www-pub), 5 = rx voor wereld (inclusief apache www-data-gebruiker)

    Groeps-ID instellen (Volledig wegnemen) bit (2) zorgt ervoor dat de groep (www-pub) wordt gekopieerd naar alle nieuwe bestanden / mappen die in die map zijn gemaakt. Andere opties zijn SETUID (4) om het gebruikers-ID te kopiëren en STICKY (1) waarvan ik denk dat alleen de eigenaar bestanden kan verwijderen.

    Er is een -R recursieve optie, maar dat maakt geen onderscheid tussen bestanden en mappen, dus dat moet gebruik find, zoals zo:

    find /var/www -type d -exec chmod 2775 {} +

  • Verander alle bestanden naar 0664

    find /var/www -type f -exec chmod 0664 {} +

  • Verander de umask voor uw gebruikers in 0002

    De umask controleert de standaardmachtigingen voor het maken van bestanden, 0002 betekent dat bestanden 664 en mappen 775 hebben. Dit instellen (door het bewerken van de umask regel onderaan /etc/profile in mijn geval) betekent dat bestanden die door één gebruiker zijn gemaakt, door andere gebruikers in de www-groep kunnen worden beschreven zonder dat dit nodig is chmod hen.

Test dit alles door een bestand en map te maken en de eigenaar, groep en machtigingen te verifiëren ls -l.

Opmerking: u moet zich afmelden voor wijzigingen in uw groepen om van kracht te worden!


201
2017-09-15 05:11



@Tom Geweldig om te zien dat je het gebruik van de findcommando hiervoor. Een kleine prestatietip die ik zou geven als je veel bestanden / mappen hebt en je gebruikt GNU find om te gebruiken + in plaats van \; zodat het commando zal werken op meerdere bestanden omdat "het is sneller om een ​​opdracht in zoveel mogelijk bestanden tegelijk uit te voeren, in plaats van één keer per bestand. Dit bespaart u de tijd die nodig is om de opdracht elke keer op te starten." Het is ook eenvoudiger om te typen omdat het geen backslash nodig heeft. - aculich
Bijgewerkt met @ aculich's suggestie om + niet te gebruiken \; - Tom
@SunnyJ. probeer dit (zonder de buitenste aanhalingstekens): "find / var / www -type f -exec chmod 0664 '{}' \ +" Probeer dat eens. Er is een spatie tussen de '{}' en de \ +. - Buttle Butkus
@ Tom- manier om het op te splitsen, bedankt. Gewoon een opmerking - ik denk dat "SETUID (4) om het gebruikers-ID te kopiëren" zoals opgenomen in uw antwoord onjuist is- SETUID wordt genegeerd wanneer het wordt toegepast op mappen in Linux / Unix - Ref - Yarin
Ok, dus door usera en userb bedoel je www-data en ftpuser ? Ik vond dit zeer verwarrend met elke vermelding van www-data, wat in de oorspronkelijke vraag was. Ook, wat is het nut / voordeel van het instellen van de eigenaar root? Moeten we het regelen ftpuser? - gskema


Ik weet niet helemaal zeker hoe je de rechten wilt configureren, maar dit kan je een startpunt geven. Er zijn waarschijnlijk betere manieren. Ik ga ervan uit dat je wilt dat beide gebruikers iets kunnen veranderen onder / var / www /

  • Maak een nieuwe groep (www-pub) en voeg de gebruikers toe aan die groep.
  • Verander het eigendom van alles onder / var / www in root: www-pub.
  • Wijzig de machtigingen van alle mappen in 2775
  • Verander alle bestanden naar 0664.
  • Verander de umask voor uw gebruikers in 0002

Dit betekent dat elk nieuw bestand dat door een van uw gebruikers wordt gemaakt de gebruikersnaam moet zijn: www-pub 0664 en elke map die wordt aangemaakt, is de gebruikersnaam: www-pub 2775. Apache krijgt leestoegang tot alles via het onderdeel 'andere gebruikers'. Het SETGID-bit in de mappen dwingt alle bestanden die worden gemaakt om eigendom te zijn van de groep die eigenaar is van de map. Het aanpassen van het umask is nodig om ervoor te zorgen dat het schrijfbit zodanig is ingesteld dat iedereen in de groep de bestanden kan bewerken.

Wat betreft hoe hard ik permissies krijg. Het hangt volledig af van de site / server. Als er maar 1-2 editors zijn en ik moet ze gewoon voorkomen dat ze dingen kapot maken, dan zal ik het rustig aan doen. Als het bedrijf iets complexers nodig had, zou ik iets complexers opzetten.


59
2018-05-11 05:49



Mogelijke toevoeging - stel cache / upload mappen in die door de webserver moeten worden geschreven naar www-data: www-data en 775. - gacrux
Zou het ook goed zijn om de gebruikers aan de apache-groep toe te voegen in plaats van te vertrouwen op 'andere' toestemmingen? Als het enige wat je doet is het uploaden van bestanden en die bestanden moeten leesbaar zijn door apache, lijkt een derde groep alleen nuttig als je die bestanden moet bewerken. - Simurr
Is er een kans dat je dit een beetje kunt uitbreiden @Zoredache? Ik gebruik het basisgebruik van rwx bits, chmod, chown, adduser, usermod, maar je bent me kwijtgeraakt met het extra eerste cijfer op de octale permissies, umasks en zo. Sommige voorbeeldopdrachten die uw geschetste benadering illustreren, worden zeer op prijs gesteld. - Tom
Op deze manier heeft elke gebruiker toegang tot alle andere gebruikersbestanden! Dit betekent dat gebruikerA config.php van gebruikerB kan lezen ... met bijvoorbeeld zijn mysql-referentie - drAlberT
Met behulp van acl kun je zowel beveiliging als collaboratieve-heid aan :) - drAlberT


Ik denk dat u POSIX ACL (toegangscontrolelijsten) wellicht nuttig vindt. Ze laten een fijner toestemmingsmodel toe in vergelijking met de gebruiker: groep: ander model. Ik heb gemerkt dat ze makkelijker te houden zijn omdat ik meer expliciet kan zijn en ook het "standaard" gedrag kan instellen voor een filiaal van het bestandssysteem.

U kunt bijvoorbeeld de machtigingen van elke gebruiker expliciet opgeven:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Of u kunt het doen op basis van een gedeelde groep:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

En misschien wilt u uw Apache-gebruiker als alleen-lezen houden

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Man-pagina's:

Tutorial


39
2018-05-11 16:26



dat is de weg ! 1 - drAlberT
ACL voor de overwinning +1 ... Voor meer informatie serverfault.com/a/360120/41823 - Yarin
Ik vraag me af of er sprake is van een lager rendement voor ACL versus basisrechten. - Buttle Butkus
Helaas ontbreekt ACL te vaak voor standaardinstallaties / distributies. Het is lastig om een ​​kernel te compileren op elke server die ik beheer of, nog erger, het bestandssysteem soms te veranderen. Bovendien moet je heel voorzichtig zijn bij het back-uppen van bestanden, vooral als je van server wisselt. ACL is geweldig, maar de huidige ondersteuning is zo laag dat ik het zou aanraden voor iedereen die geen volledige controle heeft over alles op de server en de omgeving. Maar +1 om ACL te laten zien waar het echt zinvol is! - Ninj
Goed antwoord +1; Een opmerking over het wijzigen van de lees- en schrijfrechten voor het apache-proces (www-data bijvoorbeeld) om alleen te lezen voor de hele site (via setfacl of chmod - of beide) -> Dit blokkeert uiteraard alle schrijfopdrachten (uploaden / bijwerken van de module / update vanaf de browserzijde op de meeste CMS bijvoorbeeld). Ik geloof dat veel populaire ook alleen testen op schrijftoegang op gebruikerspermniveau, niet op groepsniveau. U kunt nog steeds bijwerken, maar updates moeten handmatig worden toegepast en aangepaste machtigingen voor schrijfmappen (logs / temp / uploads / etc). Alleen-lezen is een geweldige beveiliging als uw site ermee werkt. Over het algemeen doen de meeste dat niet. - bshea


Deze vraag was opnieuw gevraagden als besproken Wat betreft meta bieden de huidige beste werkwijzen betere benaderingen dan er beschikbaar waren in 2009, toen dit werd gevraagd. Dit antwoord probeert een aantal huidige oplossingen te geven veilig omgaan met collaboratieve webontwikkelomgevingen.


Voor een veilige webserver en collaboratieve ontwikkeling zijn er meer dan alleen de bestandsrechten:

  • Heb een afzonderlijke gebruiker voor elke site d.w.z. bedient niet alle sites die gebruikmaken van www-data. Dit is belangrijk, want tegenwoordig dient Apache zelden alleen statisch inhoudsbestanden, maar actief dynamisch websites. Dit antwoord concentreert zich op PHP zoals het is meest voorkomende server-site taal, maar dezelfde principes zijn ook van toepassing op de anderen.

    Als u een beveiligingsprobleem hebt op een enkele site, kan deze worden verspreid naar elke site die wordt uitgevoerd als dezelfde gebruiker. Een aanvaller kan alles zien wat de gebruiker ziet, inclusief aanmeldingsgegevens van de database, en elke site waarop de gebruiker schrijfrechten heeft aanpassen.

  • Gebruik SSH File Transfer Protocol (SFTP). Tijdens het gebruik van FTP moet de beveiliging worden afgeschaft (omdat het zowel de wachtwoorden als de inhoud in platte tekst verzendt), maar het is een veilig alternatief. SFTP heeft ook een functie die een perfecte oplossing is voor collaboratieve webontwikkeling.

    Zodra u de sites en één gebruiker per site hebt geïsoleerd, moet u toegang verlenen aan uw webontwikkelaars, waar deze vraag over gaat. In plaats van hen de wachtwoorden te geven voor deze sitegebruikers - of toegang te krijgen tot de sitebestanden met behulp van hun persoonlijke gebruikersaccounts zoals oorspronkelijk gesuggereerd - kunt u gebruiken SSH-sleutels voor inloggen.

    Elke ontwikkelaar kan sleutelpaar genereren en de privésleutel geheim houden. Vervolgens wordt de openbare sleutel toegevoegd aan de ~/.ssh/authorized_keys bestand voor elk websitegebruikersaccount waaraan de ontwikkelaar werkt. Dit heeft veel voordelen voor het beheer van de wachtwoorden en logins:

    • Elke ontwikkelaar kan toegang krijgen tot een willekeurig aantal websites zonder de last te onthouden of alle wachtwoorden op te slaan die zijn verbonden aan de regeling voor gebruiker per site.

    • U hoeft de wachtwoorden niet te wijzigen en te delen telkens wanneer iemand het bedrijf verlaat.

    • U kunt zeer sterke wachtwoorden gebruiken of wachtwoordgebaseerde aanmelding helemaal uitschakelen.

  • Gebruik PHP-FPM. Het is de huidige aanpak voor het uitvoeren van PHP als gebruiker. Maak een nieuw zwembad voor elke gebruiker, d.w.z. één pool per elke site. Dit is het beste voor zowel beveiliging als prestaties, omdat u ook kunt aangeven hoeveel bronnen een enkele site kan gebruiken.

    Zie b.v. NeverEndingSecurity's Voer php-fpm uit met een afzonderlijke gebruiker / uid en groep op Linux. Er zijn tutorials zoals HowtoForge's PHP-FPM gebruiken met Apache op Ubuntu 16.04 die PHP-FPM niet gebruikt voor het vergroten van de beveiliging door gebruikersscheiding, leidend om een ​​enkele FPM-socket over de server te gebruiken.


7
2018-05-10 10:03