Vraag Welke machtigingen moeten mijn websitebestanden / -mappen hebben op een Linux-webserver?


Dit is een Canonical Question over bestandsmachtigingen op een Linux-webserver.

Ik heb een Linux-webserver waarop Apache2 wordt uitgevoerd met verschillende websites. Elke website heeft een eigen map in / var / www /.

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

De basisdirectory / var / www / is eigendom van root: root. Apache draait als www-data: www-data. De Fabrikam-website wordt onderhouden door twee ontwikkelaars, Alice en Bob. Beide Contoso-websites worden onderhouden door één ontwikkelaar, Eve. Op alle websites kunnen gebruikers afbeeldingen uploaden. Als een website wordt gehackt, moet de impact zo beperkt mogelijk zijn.

Ik wil weten wat de beste manier is om machtigingen in te stellen, zodat Apache de inhoud kan dienen, de website beveiligd is tegen aanvallen en de ontwikkelaars nog steeds wijzigingen kunnen aanbrengen. Een van de websites is als volgt gestructureerd:

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

Hoe moeten de machtigingen voor deze mappen en bestanden worden ingesteld? Ik heb ergens gelezen dat je nooit 777 rechten op een website moet gebruiken, maar ik begrijp niet welke problemen dit kunnen veroorzaken. Tijdens drukke periodes slaat de website sommige pagina's automatisch in de cache op en slaat de resultaten op in de cachemap. Alle inhoud die door websitebezoekers wordt ingezonden, wordt in de map met uploads opgeslagen.


283
2018-02-06 01:50


oorsprong


Dit is bedoeld als een kanoniek antwoord op alle vragen die we krijgen over websitetoestemmingen. - Nic
"Ik heb ergens gelezen dat je nooit 777 rechten op een website moet gebruiken, maar ik begrijp het niet ..." - kan de lezer dan de verdiensten van antwoorden hier inzien of ten minste kunnen vergelijken? Elke oplossing moet gebaseerd zijn op specifieke vereisten - de vereisten hier zijn niet specifiek genoeg (wat is het dreigingsmodel) - symcbean
Ik ben dol op je vraag over Apache, maar gebruik de domeinen die Microsoft doorgaans als voorbeelden gebruikt. - gWaldo
Zie ook Wat is de beste manier om toestemming te geven voor de gebruiker www-data van apache2 in / var / www? - Gareth
U kunt hier verwijzen voor volledige details over de toestemming die moet worden geplaatst op websitebestanden en -mappen in linux serverfault.com/questions/124800/...


antwoorden:


Wanneer u beslist welke machtigingen u moet gebruiken, moet u precies weten wie uw gebruikers zijn en wat ze nodig hebben. Een webserver communiceert met twee soorten gebruikers.

geauthenticeerd gebruikers hebben een gebruikersaccount op de server en kunnen worden voorzien van specifieke rechten. Dit omvat meestal systeembeheerders, ontwikkelaars en serviceaccounts. Ze maken meestal wijzigingen in het systeem met behulp van SSH of SFTP.

Anoniem gebruikers zijn de bezoekers van uw website. Hoewel ze geen rechten hebben om bestanden rechtstreeks te openen, kunnen ze een webpagina aanvragen en de webserver handelt namens hen. U kunt de toegang van anonieme gebruikers beperken door voorzichtig te zijn met welke machtigingen het webserverproces heeft. Op veel Linux-distributies draait Apache als het www-data gebruiker maar het kan anders zijn. Gebruik ps aux | grep httpd of ps aux | grep apache om te zien welke gebruiker Apache op uw systeem gebruikt.


Opmerkingen over linux-toestemmingen

Linux en andere POSIX-compatibele systemen gebruiken traditionele Unix-machtigingen. Er is een uitstekend artikel op Wikipedia over Rechten van het bestandssysteem dus ik zal hier niet alles herhalen. Maar er zijn een paar dingen waar je op moet letten.

De execute-bit
Geïnterpreteerde scripts (bijv. Ruby, PHP) werken prima zonder de toestemming voor uitvoeren. Alleen binaries en shell-scripts hebben het execute-bit nodig. Om een ​​directory te doorlopen (invoeren), moet u execute-rechten op die map hebben. De webserver heeft deze toestemming nodig om een ​​map op te sommen of alle bestanden erin weer te geven.

Standaard nieuwe bestandsrechten
Wanneer een bestand wordt gemaakt, erft het normaal de groeps-ID van degene die het heeft gemaakt. Maar soms wilt u dat nieuwe bestanden de groeps-ID van de map waarin ze zijn gemaakt, erven, zodat u het SGID-bit in de bovenliggende map zou inschakelen.

Standaard machtigingswaarden zijn afhankelijk van uw umask. De umask trekt machtigingen af ​​van nieuw gemaakte bestanden, dus de algemene waarde van 022 resulteert in het maken van bestanden met 755. Wanneer u samenwerkt met een groep, is het handig om uw umask te wijzigen in 002, zodat de bestanden die u maakt, door groepsleden kunnen worden gewijzigd. En als u de rechten van geüploade bestanden wilt aanpassen, moet u de umask voor apache wijzigen of chmod uitvoeren nadat het bestand is geüpload.


Het probleem met 777

Wanneer je chmod 777 uw website, u hebt geen enkele beveiliging. Elke gebruiker op het systeem kan elk bestand op uw website wijzigen of verwijderen. Maar serieuzer: onthoud dat de webserver optreedt namens bezoekers aan uw website en dat de webserver nu dezelfde bestanden kan wijzigen die worden uitgevoerd. Als er programmeerkwetsbaarheden in uw website zijn, kunnen deze worden misbruikt om uw website te ontleden, phishing-aanvallen in te voeren of informatie van uw server te stelen zonder dat u het ooit weet.

Bovendien, als uw server wordt uitgevoerd op een bekende poort (waarmee het moet voorkomen dat niet-rootgebruikers spawning-luisterdiensten hebben die wereldwijd toegankelijk zijn), dat betekent dat uw server moet worden gestart door root (hoewel elke normale server onmiddellijk naar een minder bevoorrechte account zal gaan zodra de poort is verbonden) . Met andere woorden, als u een webserver draait waarvan het hoofdbestand deel uitmaakt van het versiebeheer (bijv. Een CGI-app), laat u de machtigingen (of, wat dat betreft, de rechten van de bevattende map, omdat de gebruiker kan hernoemen het uitvoerbare bestand) bij 777 maakt het mogelijk ieder gebruiker om te rennen ieder uitvoerbaar als root.


Definieer de vereisten

  • Ontwikkelaars hebben lees- / schrijftoegang tot bestanden nodig, zodat ze de website kunnen bijwerken
  • Ontwikkelaars moeten lezen / schrijven / uitvoeren op mappen, zodat ze kunnen rondkijken
  • Apache heeft leestoegang tot bestanden en geïnterpreteerde scripts nodig
  • Apache heeft lezen / uitvoeren van toegang tot bruikbare mappen nodig
  • Apache heeft lezen / schrijven / uitvoeren van toegang tot mappen nodig voor geüploade inhoud

Onderhouden door een enkele gebruiker

Als slechts één gebruiker verantwoordelijk is voor het onderhoud van de site, stelt u deze in als de eigenaar van de gebruiker in de websitemap en geeft u de gebruiker volledige rwx-machtigingen. Apache moet nog steeds toegang hebben zodat het de bestanden kan bedienen, dus stel www-data in als de groepseigenaar en geef de groep r-x-machtigingen.

In jouw geval, Eve, van wie de gebruikersnaam is eve, is de enige gebruiker die onderhoudt contoso.com :

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Als u mappen hebt die door Apache kunnen worden beschreven, kunt u de machtigingswaarden voor de groepseigenaar wijzigen, zodat www-gegevens schrijftoegang heeft.

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

Het voordeel van deze configuratie is dat het voor andere gebruikers op het systeem moeilijker (maar niet onmogelijk *) wordt om rond te snuffelen, omdat alleen de gebruikers- en groepseigenaren in uw websitemap kunnen bladeren. Dit is handig als u geheime gegevens in uw configuratiebestanden hebt. Wees voorzichtig met je umask! Als u hier een nieuw bestand aanmaakt, zullen de waarden van de toestemming waarschijnlijk standaard 755 zijn. U kunt uitvoeren umask 027zodat nieuwe bestanden standaard op 640 staan ​​(rw- r-- ---).


Onderhouden door een groep gebruikers

Als meer dan één gebruiker verantwoordelijk is voor het onderhoud van de site, moet u een groep maken om te gebruiken voor het toewijzen van rechten. Het is een goede gewoonte om voor elke website een afzonderlijke groep te maken en de groep na die website een naam te geven.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

In het vorige voorbeeld gebruikten we de groepseigenaar om privileges te geven aan Apache, maar nu wordt dit gebruikt voor de ontwikkelaarsgroep. Omdat de eigenaar van de gebruiker niet meer nuttig voor ons is, is een eenvoudige manier om te zorgen dat er geen privileges worden gelekt, ingesteld op root. Apache heeft nog steeds toegang nodig, dus we geven leestoegang tot de rest van de wereld.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Als u mappen hebt die door Apache kunnen worden beschreven, kunt u van Apache de eigenaar van de gebruiker of de eigenaar van de groep maken. Hoe dan ook, het heeft alle toegang die het nodig heeft. Persoonlijk maak ik er de voorkeur aan om de eigenaar van de gebruiker te maken, zodat de ontwikkelaars nog steeds kunnen bladeren en de inhoud van uploadmappen kunnen wijzigen.

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Hoewel dit een gemeenschappelijke aanpak is, is er een keerzijde. Omdat elke andere gebruiker op het systeem dezelfde rechten heeft als Apache op uw website, kunnen andere gebruikers gemakkelijk door uw site bladeren en bestanden lezen die mogelijk geheime gegevens bevatten, zoals uw configuratiebestanden.

Je kunt je cake nemen en opeten

Dit kan verder worden verbeterd. Het is volkomen legaal voor de eigenaar om minder rechten te hebben dan de groep, dus in plaats van de gebruikerseigenaar te verspillen door deze toe te wijzen aan root, kunnen we van Apache de eigenaar van de gebruiker maken in de mappen en bestanden op uw website. Dit is een omkering van het scenario voor een enkele onderhouder, maar het werkt even goed.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Als u mappen hebt die door Apache kunnen worden beschreven, kunt u de machtigingswaarden voor de eigenaar van de gebruiker wijzigen, zodat www-gegevens schrijftoegang heeft.

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Een ding om voorzichtig te zijn met deze oplossing is dat de eigenaar van de nieuwe bestanden de maker zal matchen in plaats van op www-data. Dus alle nieuwe bestanden die u maakt, kunnen niet door Apache worden gelezen voordat u ze hebt gevonden.


* Apache privilege scheiding

Ik heb al eerder gezegd dat het voor andere gebruikers eigenlijk mogelijk is om op uw website rond te snuffelen, ongeacht welke soort privileges u gebruikt. Standaard werken alle Apache-processen als dezelfde www-gegevensgebruiker, dus elk Apache-proces kan bestanden van alle andere websites die op dezelfde server zijn geconfigureerd lezen en soms zelfs wijzigingen aanbrengen. Elke gebruiker die Apache kan krijgen om een ​​script uit te voeren, kan dezelfde toegang krijgen die Apache zelf heeft.

Om dit probleem te bestrijden, zijn er verschillende benaderingen voor scheiding van privileges in Apache. Elke aanpak heeft echter verschillende nadelen voor prestaties en beveiliging. Naar mijn mening moet elke site met hogere beveiligingsvereisten op een speciale server worden uitgevoerd in plaats van VirtualHosts op een gedeelde server.


Aanvullende overwegingen

Ik heb het niet eerder genoemd, maar het is meestal een slechte gewoonte om ontwikkelaars de website rechtstreeks te laten bewerken. Voor grotere sites is het veel beter om een ​​vrijgavesysteem te hebben waarmee de webserver wordt bijgewerkt met de inhoud van een versiecontrolesysteem. De benadering van een enkele onderhouder is waarschijnlijk ideaal, maar in plaats van een persoon heeft u geautomatiseerde software.

Als uw website uploads toestaat die niet hoeven te worden opgediend, moeten die uploads ergens buiten de root van het web worden opgeslagen. Anders zou je kunnen merken dat mensen bestanden downloaden die bedoeld waren om geheim te zijn. Als u bijvoorbeeld studenten toestaat opdrachten in te dienen, moeten ze worden opgeslagen in een map die niet wordt aangeboden door Apache. Dit is ook een goede benadering voor configuratiebestanden die geheimen bevatten.

Voor een website met meer complexe vereisten, wilt u misschien kijken naar het gebruik van Toegangscontrolelijsten. Deze maken een veel geavanceerdere besturing van privileges mogelijk.

Als uw website complexe vereisten heeft, wilt u misschien een script schrijven dat alle rechten instelt. Test het grondig en bewaar het dan veilig. Het kan zijn gewicht in goud waard zijn als je ooit vindt dat je om wat voor reden dan ook je website moet herbouwen.


316
2018-02-06 01:50



"chmod -R 775 fabrikam.com". Zeer weinig bestanden binnen de meeste websites moeten uitvoerbaar zijn; bijv. php-script kan 0640 zijn zolang de webserver ze kan lezen. chmod -R a + X fabrikam.com zou uitvoerbare rechten geven aan iedereen alleen in mappen.
leuke beschrijving! - RNA
Houd er rekening mee dat Apache wordt uitgevoerd als gebruiker apache op van Red Hat afgeleide systemen. - Michael Hampton♦
Dit is uitstekend, maar er was één ding dat ik niet begreep: ik begrijp niet het doel of het voordeel van de strategie om van apache de gebruiker / eigenaar van een directory van bestanden te maken als deze al eigenaar is van de groep over het bestand. - idiotprogrammer
Dit is een uitstekende post. Hier is mijn bijdrage: Het nadeel van het gebruik van www-data als eigenaar en dev-fabrikam als groep (genoemd in Je kunt je cake nemen en opeten geldt ook (omgekeerd) voor het scenario dat wordt aangeboden in Onderhouden door een enkele gebruiker. In dat scenario heeft de gebruiker, wanneer Apache een map of bestand maakt, geen toegang ertoe, zodat de bestanden teruggestuurd moeten worden naar de oorspronkelijke gebruiker. Ik heb het antwoord niet bijgewerkt, omdat ik niet 100% zeker ben van mijn verklaring. Ik wil liever dat anderen dit bevestigen voordat het antwoord wordt gepatcht.


Ik vraag me af waarom zoveel mensen het "andere" (o) deel van de Linux-rechten gebruiken (of aanbevelen) om te bepalen wat Apache (en / of PHP) kan doen. Door dit rechterdeel in te stellen op iets anders dan "0", staat u de hele wereld toe iets te doen in het bestand / de map.

Mijn aanpak volgt:

  • Ik maak twee afzonderlijke gebruikers. Eén voor de SSH / SFTP-toegang (indien nodig), die alle bestanden bezit, en een voor de PHP FastCGI-gebruiker (de gebruiker die de website zal uitvoeren zoals). Laten we deze gebruikers respectievelijk noemen bob en bob-www.
  • bob heeft volledige rechten (rwx op mappen, rw- op bestanden), zodat hij / zij de hele website kan lezen en bewerken.
  • Het PHP FastCGI-proces heeft nodig r-x rechten op mappen en r-- rechten op bestanden, behalve voor zeer specifieke mappen zoals cache/ of uploads/, waar de "schrijf" toestemming ook nodig is. Om PHP FastCGI deze mogelijkheid te geven, werkt het als bob-www, en bob-www wordt toegevoegd aan de automatisch gemaakte bob groep.
  • We zorgen er nu voor dat de eigenaar en de groep van alle mappen en bestanden zijn Bob.
  • Er ontbreekt iets: zelfs wij gebruiken FastCGI, maar Apache heeft nog steeds leestoegang nodig voor statische inhoud of .htaccess-bestanden die het zal proberen te lezen als AllowOverride is ingesteld op iets anders dan None. Om het gebruik van de te vermijden O een deel van de rechten, voeg ik de www-data gebruiker van de bob groep.

Nu:

  • Om te bepalen wat de ontwikkelaar kan doen, kunnen we spelen met de u een deel van de rechten (maar dit is de opmerking hieronder).
  • Om te bepalen wat Apache en PHP kunnen doen, kunnen we spelen met de g een deel van de rechten.
  • De O deel is altijd ingesteld op 0, zodat niemand anders op de server de website kan lezen of bewerken.
  • Er is geen probleem wanneer bob gebruiker maakt nieuwe bestanden aan, omdat deze automatisch tot de hoofdgroep behoren (bob).

Dit is een samenvatting, maar in deze situatie bob is toegestaan ​​voor SSH. Als er geen gebruiker mag zijn om de website aan te passen (bijv. Klant wijzigt de website alleen via een CMS admin panel en heeft geen Linux kennis), creëer sowieso twee gebruikers, maar geef /bin/falseals shell voor bob ook en schakel de login uit.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Notitie : mensen vergeten vaak dat het beperken van de u (eigenaar) rechten zijn meestal nutteloos en onveilig, omdat de eigenaar van een bestand de chmod commando, zelfs de rechten zijn 000.

Vertel me of mijn aanpak beveiligingsproblemen heeft, omdat ik niet 100% zeker ben, maar het is wat ik gebruik.

Ik denk dat deze configuratie een probleem heeft: wanneer PHP / Apache een nieuw bestand aanmaakt (bijv. Uploaden), zal het daar toe behoren bob-www: bob, en bob kan het alleen lezen. Misschien kan setuid in de directory het probleem oplossen.


13
2017-07-19 21:42



Linux negeert setuid. Nieuwe bestanden zijn altijd in het bezit van de maker. - Paul
Ik begrijp iets niet. Dit lijkt niet de situatie op te nemen wanneer meerdere ontwikkelaars gelijktijdig op de website werken, aangezien de enige gebruiker is bob. Hoe ga je daarmee om? Bijv. via ssh loggen beide gebruikers in als bob. Bob (1) voelt dat hij / zij het wachtwoord niet kan onthouden en verandert het in een ander maar nog steeds veilig. bob (2) probeert zich de volgende keer aan te melden en hij / zij niet. - n611x007
@naxa Elk marginaal goed systeem mag nooit een van de ontwikkelaars hebben die de website direct aanpast. Idealiter is de website onder versiebeheer, zodanig dat het gebruikersaccount 'bob' elke (stabiele) release automatisch trekt en implementeert. Dus de ontwikkelaars doen de ontwikkeling offsite en wijzigingen worden geïmplementeerd zodra ze naar de implementatieserver worden gepusht. 'bob' is een systeemgebruiker die zeer beperkte netwerkmachtigingen moet hebben, die geen externe aanmelding omvatten; Met iptables kun je eigenlijk filteren op UID voor dingen als deze. - Parthian Shot
"Ik vraag me af waarom zoveel mensen het" andere "(o) deel gebruiken (of aanbevelen)" - en misschien had je dit moeten plaatsen als een vraag in plaats van als een antwoord. Het is niet ongebruikelijk om opzettelijk de webserver (als het meest blootgestelde deel van het systeem) met het laagste privilegegraad uit te voeren, terwijl ondersteuning, ontwikkeling en beheerdersaccounts ook andere toegang vereisen - symcbean


Gezien de Google-rangorde op het bovenstaande uitstekende antwoord, denk ik dat er één ding moet worden opgemerkt, en het lijkt erop dat ik na het antwoord geen notitie achterlaat.

Als u verdergaat met het voorbeeld, als u van plan bent om www-data als eigenaar en dev-fabrikam te gebruiken als groep met 570 rechten op de directory (of bestand), is het belangrijk om op te merken dat Linux negeert  setuid, dus alle nieuwe bestanden zijn eigendom van de gebruiker die ze heeft gemaakt. Dit betekent dat u na het aanmaken van nieuwe mappen en bestanden iets moet gebruiken dat lijkt op:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

In Ubuntu 12.04 voor Rackspace OpenStack had ik een vreemd probleem waarbij ik de rechten 570 niet kon laten werken totdat ik de server opnieuw opstartte, wat het probleem op magische wijze heeft opgelost. Verloor haren in toenemende mate aan dat ogenschijnlijk simpele probleem ...


9
2018-01-13 22:03



Laat dit alstublieft worden googled: In Raspbian (ook bekend als een raspberry pi, als je het eigendom van / var / www onder lighttpd (of een andere webbrowser) wilt wijzigen, MOET je opnieuw opstarten. - gbronner
@gbronner Als dat een moeilijk probleem is om de oplossing voor te vinden, kun je overwegen om het als een vraag te plaatsen en een antwoord op de vraag te geven. Het is echter waarschijnlijk meer geschikt in een andere SE Q & A-site. Mijn gok is Unix en Linux kan een goede plek zijn om dat te doen. - Paul
Er is ook raspberrypi.stackexchange.com; het lijkt erop dat de SE-sites de kennis een beetje versnipperen. - gbronner
@gbronner lol. Ik wist dat niet! De Raspbian-tag op U & L heeft ongeveer 120 vragen. - Paul


Ik ga met deze configuratie:

  1. Alle mappen behalve uploadt een set naar de eigenaar root en groep root, machtigingen voor 0755.
  2. Alle bestanden ingesteld op eigenaar root en groep root, machtigingen voor 0644.
  3. Uploadt directory ingesteld op eigenaar root, groep www-data, machtigingen voor 1770. Het kleverige bit laat de groepseigenaar de directory en de bestanden in de bit niet verwijderen of hernoemen.
  4. Binnen uploadt de map een nieuwe map met www-data eigenaar, gebruiker en groep, en 0700 rechten voor elk www-data gebruiker die bestanden uploadt.
  5. Apache-configuratie:

Ontkennen AllowOverride en Index in de uploaddirectory, zodat Apache niet leest .htaccess bestanden, en de Apache-gebruiker kan de inhoud van de uploadmap niet indexeren:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.ini configuratie:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

Met deze configuratie, de www-data gebruiker zal niet in andere directories kunnen komen dan siteDir/  /tmp en /usr/share/phpmyadmin. U kunt ook de maximale bestandsgrootte, de maximale berichtgrootte en de maximaal te uploaden bestanden in dezelfde aanvraag beheren.


3
2017-10-23 09:54





Wanneer u een FTP-gebruiker genaamd "leo" nodig heeft om bestanden te uploaden naar de webdirectory van example.com en u ook uw gebruiker "apache" moet kunnen maken om uploa-bestanden / sessies / cachebestanden in de cachedirectory te maken, doe dan als volgt:

Met deze opdracht wordt leo als eigenaar en groep toegewezen als apache aan example.com, apache-gebruiker maakt deel uit van groepsapache zodat deze de rechten van de apachegroep overneemt

chown -R leo: apache example.com

Een ander commando dat juiste toestemming en veiligheidsproblemen verzekert.

chmod-R 2774 example.com

Hier is eerste nummer 2 voor directory en verzekert dat elk nieuw gemaakt bestand in dezelfde groep en eigenaarsrechten blijft. 77 is voor eigenaar en groep betekent dat ze volledige toegang hebben. 4 is voor anderen betekent dat ze alleen kunnen lezen via.

volgen is handig om toestemmingsnummers te begrijpen

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

3
2017-08-09 07:15