Izin apa yang harus dimiliki file / folder situs web saya pada server web Linux?

310

Ini adalah Pertanyaan Canonical tentang Izin File di server web Linux.

Saya memiliki server web Linux yang menjalankan Apache2 yang menampung beberapa situs web. Setiap situs web memiliki folder sendiri di / var / www /.

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

Direktori dasar / var / www / dimiliki oleh root: root. Apache berjalan sebagai www-data: www-data. Situs web Fabrikam dikelola oleh dua pengembang, Alice dan Bob. Kedua situs web Contoso dikelola oleh satu pengembang, Eve. Semua situs web memungkinkan pengguna untuk mengunggah gambar. Jika situs web dikompromikan, dampaknya harus sebatas mungkin.

Saya ingin tahu cara terbaik untuk mengatur izin agar Apache dapat menyajikan konten, situs web aman dari serangan, dan pengembang masih bisa melakukan perubahan. Salah satu situs web terstruktur seperti ini:

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

Bagaimana seharusnya izin ditetapkan pada direktori dan file ini? Saya membaca di suatu tempat bahwa Anda tidak boleh menggunakan 777 izin di situs web, tetapi saya tidak mengerti masalah apa yang bisa menyebabkannya. Selama periode sibuk, situs web secara otomatis menyimpan beberapa halaman dan menyimpan hasilnya dalam folder cache. Semua konten yang dikirimkan oleh pengunjung situs web disimpan ke folder unggahan.

Nic
sumber
6
Ini dimaksudkan sebagai jawaban kanonik untuk semua pertanyaan yang kami dapatkan tentang izin situs web.
Nic
"Saya membaca di suatu tempat bahwa Anda seharusnya tidak pernah menggunakan izin 777 di situs web, tetapi saya tidak mengerti ..." - maka apakah pembaca akan dapat memahami atau setidaknya dapat membandingkan nilai jawaban di sini? Solusi apa pun harus didasarkan pada persyaratan spesifik - persyaratan di sini tidak cukup spesifik (apa model ancamannya)
symcbean
6
Saya suka bahwa Anda bertanya tentang Apache, tetapi menggunakan domain yang biasanya digunakan Microsoft sebagai contoh.
gWaldo
Anda dapat merujuk di sini untuk perincian lengkap tentang izin yang harus diletakkan pada file dan folder situs web di linux serverfault.com/questions/124800/…

Jawaban:

342

Saat memutuskan izin apa yang akan digunakan, Anda harus tahu persis siapa pengguna Anda dan apa yang mereka butuhkan. Server web berinteraksi dengan dua jenis pengguna.

Pengguna terotentikasi memiliki akun pengguna di server dan dapat diberikan hak khusus. Ini biasanya termasuk administrator sistem, pengembang, dan akun layanan. Mereka biasanya melakukan perubahan pada sistem menggunakan SSH atau SFTP.

Pengguna anonim adalah pengunjung situs web Anda. Meskipun mereka tidak memiliki izin untuk mengakses file secara langsung, mereka dapat meminta halaman web dan server web bertindak atas nama mereka. Anda dapat membatasi akses pengguna anonim dengan berhati-hati tentang izin apa yang dimiliki proses server web. Pada banyak distribusi Linux, Apache berjalan sebagai www-datapengguna tetapi bisa berbeda. Gunakan ps aux | grep httpdatau ps aux | grep apacheuntuk melihat apa yang digunakan pengguna Apache di sistem Anda.


Catatan tentang izin linux

Linux dan sistem yang mendukung POSIX lainnya menggunakan izin unix tradisional. Ada artikel yang bagus di Wikipedia tentang izin Filesystem jadi saya tidak akan mengulang semuanya di sini. Tetapi ada beberapa hal yang harus Anda waspadai.

Eksekusi bit
Skrip yang diartikan (mis. Ruby, PHP) berfungsi baik tanpa izin eksekusi Hanya binari dan skrip shell yang memerlukan bit eksekusi. Untuk melintasi (masuk) direktori, Anda harus memiliki izin eksekusi pada direktori itu. Server web memerlukan izin ini untuk mendaftar direktori atau melayani file apa pun di dalamnya.

Izin file baru default
Ketika file dibuat, biasanya mewarisi id grup dari siapa pun yang membuatnya. Tetapi kadang-kadang Anda ingin file baru untuk mewarisi id grup folder tempat mereka dibuat, sehingga Anda akan mengaktifkan bit SGID pada folder induk.

Nilai izin default bergantung pada umask Anda. Umask mengurangi izin dari file yang baru dibuat, sehingga nilai umum dari 022 menghasilkan 755 file yang dibuat. Ketika berkolaborasi dengan grup, ada baiknya mengubah umask Anda menjadi 002 sehingga file yang Anda buat dapat dimodifikasi oleh anggota grup. Dan jika Anda ingin menyesuaikan izin file yang diunggah, Anda perlu mengubah umask untuk apache atau menjalankan chmod setelah file diunggah.


Masalah dengan 777

Ketika Anda chmod 777situs web Anda, Anda tidak memiliki keamanan apa pun. Setiap pengguna di sistem dapat mengubah atau menghapus file apa pun di situs web Anda. Tetapi yang lebih serius, ingatlah bahwa server web bertindak atas nama pengunjung ke situs web Anda, dan sekarang server web dapat mengubah file yang sama dengan yang dijalankannya. Jika ada kerentanan pemrograman di situs web Anda, mereka dapat dieksploitasi untuk merusak situs web Anda, memasukkan serangan phishing, atau mencuri informasi dari server Anda tanpa Anda ketahui.

Selain itu, jika server Anda berjalan pada port yang terkenal (yang seharusnya mencegah pengguna non-root memunculkan layanan mendengarkan yang dapat diakses oleh dunia), itu berarti server Anda harus dimulai dengan root (meskipun server waras mana pun akan segera turun ke akun yang kurang istimewa setelah port terikat). Dengan kata lain, jika Anda menjalankan server web di mana executable utama adalah bagian dari kontrol versi (misalnya aplikasi CGI), meninggalkan izinnya (atau, dalam hal ini, izin direktori yang berisi, karena pengguna dapat mengubah nama yang dapat dieksekusi) di 777 memungkinkan setiap pengguna untuk menjalankan semua yang dapat dieksekusi sebagai root.


Tetapkan persyaratan

  • Pengembang perlu akses baca / tulis ke file sehingga mereka dapat memperbarui situs web
  • Pengembang perlu membaca / menulis / mengeksekusi pada direktori sehingga mereka dapat menelusuri
  • Apache membutuhkan akses baca ke file dan skrip yang ditafsirkan
  • Apache perlu membaca / mengeksekusi akses ke direktori yang dapat dilayani
  • Apache perlu membaca / menulis / mengeksekusi akses ke direktori untuk konten yang diunggah

Dikelola oleh satu pengguna

Jika hanya satu pengguna yang bertanggung jawab untuk memelihara situs tersebut, tetapkan mereka sebagai pemilik pengguna pada direktori situs web dan berikan izin penuh kepada pengguna. Apache masih membutuhkan akses sehingga dapat melayani file, jadi atur data-www sebagai pemilik grup dan berikan izin grup rx.

Dalam kasus Anda, Eve, yang mungkin memiliki nama pengguna eve, adalah satu-satunya pengguna yang mengelola 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

Jika Anda memiliki folder yang perlu ditulis oleh Apache, Anda bisa memodifikasi nilai izin untuk pemilik grup sehingga www-data memiliki akses tulis.

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

Manfaat dari konfigurasi ini adalah menjadi lebih sulit (tetapi bukan tidak mungkin *) bagi pengguna lain pada sistem untuk mengintip, karena hanya pemilik pengguna dan grup yang dapat menelusuri direktori situs web Anda. Ini berguna jika Anda memiliki data rahasia dalam file konfigurasi Anda. Hati-hati dengan umask Anda! Jika Anda membuat file baru di sini, nilai izin mungkin akan default ke 755. Anda dapat menjalankan umask 027sehingga file baru default ke 640 ( rw- r-- ---).


Dikelola oleh sekelompok pengguna

Jika lebih dari satu pengguna bertanggung jawab untuk memelihara situs, Anda perlu membuat grup untuk digunakan untuk menetapkan izin. Merupakan praktik yang baik untuk membuat grup terpisah untuk setiap situs web, dan beri nama grup tersebut setelah situs web itu.

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

Pada contoh sebelumnya, kami menggunakan pemilik grup untuk memberikan hak istimewa kepada Apache, tetapi sekarang digunakan untuk grup pengembang. Karena pemilik pengguna tidak berguna lagi bagi kami, mengaturnya untuk root adalah cara sederhana untuk memastikan bahwa tidak ada hak istimewa bocor. Apache masih membutuhkan akses, jadi kami memberikan akses baca ke seluruh dunia.

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

Jika Anda memiliki folder yang harus dapat ditulis oleh Apache, Anda dapat membuat Apache sebagai pemilik pengguna atau pemilik grup. Apa pun itu, ia akan memiliki semua akses yang dibutuhkan. Secara pribadi, saya lebih suka menjadikannya pemilik pengguna sehingga pengembang masih dapat menelusuri dan memodifikasi konten folder unggahan.

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

Meskipun ini adalah pendekatan umum, ada sisi buruknya. Karena setiap pengguna lain di sistem memiliki hak yang sama untuk situs web Anda seperti halnya Apache, maka mudah bagi pengguna lain untuk menjelajahi situs Anda dan membaca file yang mungkin berisi data rahasia, seperti file konfigurasi Anda.

Anda dapat memiliki kue dan memakannya juga

Ini bisa lebih ditingkatkan. Sangat sah bagi pemilik untuk memiliki lebih sedikit keistimewaan daripada grup, jadi alih-alih menyia-nyiakan pemilik pengguna dengan menugaskannya untuk melakukan rooting, kita dapat menjadikan Apache pemilik pengguna di direktori dan file di situs web Anda. Ini adalah pembalikan dari skenario pemelihara tunggal, tetapi berfungsi sama baiknya.

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

Jika Anda memiliki folder yang perlu ditulis oleh Apache, Anda bisa memodifikasi nilai izin untuk pemilik pengguna sehingga www-data memiliki akses tulis.

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

Satu hal yang perlu diperhatikan dalam solusi ini adalah bahwa pemilik pengguna file baru akan cocok dengan pembuatnya daripada disetel ke data-www. Jadi setiap file baru yang Anda buat tidak akan dapat dibaca oleh Apache sampai Anda mengetahuinya.


* Pemisahan hak istimewa Apache

Saya sebutkan sebelumnya bahwa sebenarnya mungkin bagi pengguna lain untuk menyelinap di situs web Anda, apa pun hak istimewa yang Anda gunakan. Secara default, semua proses Apache berjalan sebagai pengguna data-www yang sama, sehingga setiap proses Apache dapat membaca file dari semua situs web lain yang dikonfigurasi pada server yang sama, dan kadang-kadang bahkan membuat perubahan. Setiap pengguna yang dapat membuat Apache menjalankan skrip dapat memperoleh akses yang sama dengan yang dimiliki oleh Apache itu sendiri.

Untuk mengatasi masalah ini, ada berbagai pendekatan untuk pemisahan hak istimewa di Apache. Namun, setiap pendekatan dilengkapi dengan berbagai kelemahan kinerja dan keamanan. Menurut pendapat saya, situs apa pun dengan persyaratan keamanan yang lebih tinggi harus dijalankan pada server khusus alih-alih menggunakan VirtualHost di server bersama.


Pertimbangan tambahan

Saya tidak menyebutkannya sebelumnya, tetapi biasanya merupakan praktik yang buruk untuk membuat pengembang mengedit situs web secara langsung. Untuk situs yang lebih besar, Anda lebih baik memiliki semacam sistem rilis yang memperbarui server web dari konten sistem kontrol versi. Pendekatan pengelola tunggal mungkin ideal, tetapi alih-alih orang yang memiliki perangkat lunak otomatis.

Jika situs web Anda memungkinkan unggahan yang tidak perlu dilayani, unggahan itu harus disimpan di suatu tempat di luar root web. Jika tidak, Anda mungkin menemukan bahwa orang-orang mengunduh file yang dimaksudkan untuk dirahasiakan. Misalnya, jika Anda mengizinkan siswa mengirimkan tugas, tugas itu harus disimpan ke direktori yang tidak dilayani oleh Apache. Ini juga merupakan pendekatan yang baik untuk file konfigurasi yang mengandung rahasia.

Untuk situs web dengan persyaratan yang lebih kompleks, Anda mungkin ingin melihat ke dalam penggunaan Daftar Kontrol Akses . Ini memungkinkan kontrol hak istimewa yang jauh lebih canggih.

Jika situs web Anda memiliki persyaratan yang rumit, Anda mungkin ingin menulis skrip yang mengatur semua izin. Uji dengan seksama, lalu amankan. Beratnya bisa bernilai emas jika Anda merasa perlu membangun kembali situs web Anda karena alasan tertentu.

Nic
sumber
10
"chmod -R 775 fabrikam.com". Sangat sedikit file di dalam sebagian besar situs web yang harus dapat dieksekusi; misalnya skrip php dapat sepanjang 0640 selama server web dapat membacanya. chmod -R a + X fabrikam.com akan memberikan hak yang dapat dieksekusi kepada semua orang hanya pada direktori.
7
Perhatikan juga bahwa Apache berjalan sebagai pengguna apachepada sistem berasal Red Hat.
Michael Hampton
Ini sangat bagus, tetapi ada satu hal yang saya tidak mengerti: Saya tidak mengerti tujuan atau keuntungan dari strategi membuat apache pengguna / pemilik direktori file jika sudah memiliki kepemilikan grup atas file tersebut.
idiotprogrammer
Jawaban ini, meski komprehensif, hanya berkaitan dengan izin DAC. Saya pikir izin MAC harus dipertimbangkan juga.
dawud
1
Ini adalah pos yang sangat bagus. Inilah kontribusi saya: Kelemahan menggunakan www-data sebagai pemilik dan dev-fabrikam sebagai grup (disebutkan dalam Anda dapat memiliki kue dan memakannya juga berlaku (secara terbalik) untuk skenario yang ditawarkan di Dikelola oleh satu pengguna . skenario, setiap kali Apache membuat folder atau file, pengguna tidak akan memiliki akses ke sana sehingga file-file tersebut perlu dicacah kembali ke pengguna asli. Saya belum memperbarui jawabannya karena saya tidak 100% yakin tentang pernyataan saya Saya lebih suka ada orang lain yang mengkonfirmasi sebelum menambal jawabannya
14

Saya bertanya-tanya mengapa begitu banyak orang menggunakan (atau merekomendasikan) bagian "lain" (o) dari hak Linux untuk mengontrol apa yang dapat dilakukan Apache (dan / atau PHP). Dengan mengatur bagian kanan ini ke sesuatu selain "0", Anda hanya mengizinkan seluruh dunia untuk melakukan sesuatu pada direktori file /.

Pendekatan saya adalah sebagai berikut:

  • Saya membuat dua pengguna yang terpisah. Satu untuk akses SSH / SFTP (jika perlu), yang akan memiliki semua file, dan satu untuk pengguna PHP FastCGI (pengguna situs web akan dijalankan sebagai). Sebut masing-masing pengguna ini bob dan bob-www .
  • bob akan memiliki hak penuh ( rwx pada folder, rw- pada file), sehingga ia dapat membaca dan mengedit seluruh situs web.
  • Proses PHP FastCGI membutuhkan hak rx pada folder dan hak r-- pada file, kecuali folder yang sangat spesifik seperti cache/atau uploads/, di mana izin "tulis" juga diperlukan. Untuk memberikan PHP FastCGI kemampuan ini, ia akan berjalan sebagai bob-www , dan bob-www akan ditambahkan ke grup bob yang dibuat secara otomatis .
  • Kami sekarang memastikan pemilik dan grup dari semua direktori dan file bob bob .
  • Ada yang hilang: bahkan kami menggunakan FastCGI, tetapi Apache masih membutuhkan akses baca, untuk konten statis, atau file .htaccess yang akan coba dibaca jika AllowOverridedisetel ke sesuatu yang lain dari pada None. Untuk menghindari penggunaan bagian o dari hak, saya menambahkan pengguna data-www ke grup bob .

Sekarang:

  • Untuk mengontrol apa yang bisa dilakukan pengembang, kita bisa bermain dengan Anda bagian dari hak (tapi ini catatan di bawah).
  • Untuk mengontrol apa yang dapat dilakukan oleh Apache dan PHP, kita dapat bermain dengan bagian g dari hak tersebut.
  • Bagian o selalu diatur ke 0, sehingga tidak ada orang lain di server yang dapat membaca atau mengedit situs web.
  • Tidak ada masalah ketika pengguna bob membuat file baru, karena itu akan secara otomatis menjadi milik kelompok utama ( bob ).

Ini adalah rekap, tetapi dalam situasi ini, bob diizinkan untuk SSH. Jika seharusnya tidak ada pengguna yang diizinkan untuk memodifikasi situs web (mis. Pelanggan hanya memodifikasi situs web melalui panel admin CMS dan tidak memiliki pengetahuan Linux), tetap buat dua pengguna, tetapi berikan /bin/falsejuga shell untuk bob , dan nonaktifkan loginnya.

    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 {} \;

Catatan: orang cenderung lupa bahwa membatasi hak u (pemilik) chmodseringkali tidak berguna dan tidak aman, karena pemilik file dapat menjalankan perintah, bahkan haknya adalah 000.

Katakan jika pendekatan saya memiliki beberapa masalah keamanan, karena saya tidak 100% yakin, tetapi itulah yang saya gunakan.

Saya pikir konfigurasi ini memiliki masalah: ketika PHP / Apache membuat file baru (mis. Mengunggah), itu akan menjadi milik bob-www: bob , dan bob hanya akan dapat membacanya. Mungkin setuid pada direktori dapat menyelesaikan masalah.

Rubah
sumber
Linux mengabaikan setuid. File baru selalu dimiliki oleh pencipta.
Paul
Saya tidak mengerti sesuatu. Ini sepertinya tidak memasukkan situasi ketika lebih banyak pengembang bekerja secara simultan di situs web, karena satu-satunya pengguna adalah bob. Bagaimana Anda menghadapinya? Misalnya. melalui ssh, kedua pengguna masuk sebagai bob. bob (1) merasa dia tidak dapat mengingat kata sandi dan mengubahnya ke yang lain tetapi masih aman. bob (2) mencoba masuk kali berikutnya, dan ia tidak bisa.
n611x007
2
@naxa Setiap sistem yang secara umum baik seharusnya tidak memiliki pengembang yang secara langsung memodifikasi situs web. Idealnya, situs web berada di bawah kontrol versi sehingga akun pengguna 'bob' menarik dan menyebarkan setiap rilis (stabil) secara otomatis. Jadi, pengembang melakukan pengembangan di luar lokasi, dan perubahan dikerahkan begitu mereka didorong ke server penempatan. 'bob' adalah pengguna sistem yang seharusnya memiliki izin jaringan yang sangat terbatas, yang tidak termasuk login jarak jauh; iptables sebenarnya memungkinkan Anda untuk memfilter oleh UID untuk hal-hal seperti ini.
Parthian Shot
"Saya bertanya-tanya mengapa begitu banyak orang menggunakan (atau merekomendasikan) bagian" lain "(o)" - maka mungkin Anda seharusnya memposting ini sebagai pertanyaan daripada jawaban. Bukan hal yang aneh untuk secara sengaja menjalankan server web (sebagai bagian yang paling terbuka dari sistem) dengan tingkat privilege terendah sementara dukungan, pengembangan, akun admin juga memerlukan akses yang berbeda
symcbean
@ParthianShot Anda tidak bisa memaksakan itu kepada pihak ketiga (ketika situs tidak dikelola oleh Anda, tetapi folder itu ada di server Anda). Terkadang satu-satunya hal yang mereka tahu harus dilakukan adalah dengan menggunakan ftp.
Peregring-lk
9

Mengingat peringkat google pada jawaban yang sangat baik di atas, saya pikir ada satu hal yang harus dicatat, dan saya tidak bisa meninggalkan catatan setelah jawaban.

Melanjutkan dengan contoh, jika Anda berencana untuk menggunakan www-data sebagai pemilik dan dev-fabrikam sebagai grup dengan 570 izin pada direktori (atau file), penting untuk dicatat bahwa Linux mengabaikan setuid , sehingga semua file baru akan dimiliki oleh pengguna yang membuatnya. Ini berarti bahwa setelah membuat direktori dan file baru Anda harus menggunakan sesuatu yang mirip dengan:

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

Di Ubuntu 12.04 untuk Rackspace OpenStack, saya memiliki masalah aneh di mana saya tidak bisa mendapatkan izin 570 untuk bekerja sampai saya reboot server, yang secara ajaib memperbaiki masalah tersebut. Kehilangan rambut pada tingkat yang meningkat atas masalah yang tampaknya sederhana ....

Paul
sumber
Tolong biarkan ini googled: Dalam Raspbian (alias pada raspberry pi, jika Anda ingin mengubah kepemilikan / var / www di bawah lighttpd (atau browser web lain), Anda HARUS reboot.
gbronner
@gbronner Jika itu adalah masalah sulit untuk menemukan resolusi, Anda dapat mempertimbangkan mempostingnya sebagai pertanyaan dan memberikan jawaban untuk pertanyaan itu. Namun, itu mungkin lebih tepat di situs T&J SE yang berbeda. Dugaan saya adalah Unix & Linux mungkin tempat yang bagus untuk melakukan itu.
Paul
1
Ada juga raspberrypi.stackexchange.com; tampaknya situs SE memecah belah pengetahuan sedikit.
gbronner
@gbronner lol. Saya tidak tahu tentang itu! Tag Raspbian pada U&L memiliki sekitar 120 pertanyaan.
Paul
3

Saya pergi dengan konfigurasi ini:

  1. Semua direktori kecuali mengunggah satu set ke pemilik rootdan grup root, izin untuk 0755.
  2. Semua file diatur ke pemilik rootdan grup root, izin untuk 0644.
  3. Direktori unggahan diatur ke pemilik root, grup www-data, izin untuk 1770. Bit lengket tidak membiarkan pemilik grup menghapus atau mengganti nama direktori dan file di dalamnya.
  4. Di dalam folder unggahan direktori baru dengan www-datapengguna dan grup pemilik, dan 0700izin untuk setiap www-datapengguna yang mengunggah file.
  5. Konfigurasi Apache:

Tolak AllowOverridedan Indexdalam direktori unggahan, sehingga Apache tidak membaca .htaccessfile, dan pengguna Apache tidak dapat mengindeks konten folder unggahan:

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

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

6. php.inikonfigurasi:

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

Dengan konfigurasi ini, www-datapengguna tidak akan bisa masuk ke direktori selain siteDir/ /tmpdan /usr/share/phpmyadmin. Anda juga dapat mengontrol ukuran file maksimum, ukuran posting maksimum dan file maksimum untuk diunggah dalam permintaan yang sama.

Manolo
sumber
3

Ketika Anda memiliki pengguna FTP yang disebut "leo" perlu mengunggah file ke direktori web example.com dan Anda juga meminta pengguna "apache" Anda untuk dapat membuat file uploa / sesi / cache file dalam direktori cache kemudian lakukan hal berikut:

Perintah ini menetapkan leo sebagai pemilik dan grup sebagai apache ke example.com, pengguna apache adalah bagian dari apache grup sehingga akan mewarisi izin grup apache

chown -R leo: apache example.com

Perintah lain yang menjamin izin yang tepat dan memenuhi masalah keamanan juga.

chmod -R 2774 example.com

Di sini nomor 2 yang pertama adalah untuk direktori dan memastikan setiap file baru yang dibuat akan tetap berada di grup dan izin pemilik yang sama. 77 untuk pemilik dan grup berarti mereka memiliki akses penuh. 4 untuk orang lain berarti mereka hanya bisa membaca.

berikut ini membantu untuk memahami nomor izin

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
Krishan Gopal
sumber
1

IMO kita harus memperhitungkan:

  • apakah Anda memercayai proses yang membaca file Anda? misalnya. PHP?

Mari kita asumsikan Anda memiliki server yang berbagai data di bawah 'pengujian' pengguna.

Pengguna 'test' ada di sana:

  • datanya di $HOMEDIR
  • suratnya masuk $MAIL
  • datanya untuk web di /var/www/test

Sekarang mari kita pikirkan:

  • aplikasi web berjalan di bawah testpengguna (PHP-FPM) - itu dapat menghapus file-nya!
  • aplikasi web berjalan di bawah testgrup (PHP-FPM) - itu dapat menghapus file-nya di mana direktori memiliki 'w' untuk grup dan dapat memodifikasi file apa pun yang memiliki 'r' untuk grup; dan masih bisa membacanya - kunci ssh Anda misalnya!

Mari kita asumsikan PHP buggy, dan itu, apakah Anda percaya open_basedir? Apakah Anda chrootproses PHP Anda? Apa yang tidak Anda lakukan, apakah Anda menginginkannya merayapi semua sistem file?

Proses aplikasi web Anda, mis. PHP-FPM, maka harus:

  • dibatasi untuk jalur tertentu melalui chroot
  • tidak boleh berjalan di bawah izin pengguna primer atau grup primer pemilik data

Dengan demikian Anda dapat melakukan:

  • pengguna uji adalah: test:test
  • pengguna uji dalam kelompok sekunder misalnya. test-www
  • aplikasi web (PHP-FPM) berjalan di bawah test-www:test-www
  • uji pengguna jika ia ingin agar aplikasi web dapat membaca file-nya akan: chmod u=rwX,g=rX,o= /var/www/test/public
  • uji pengguna jika dia ingin aplikasi web dapat menulis ke jalur data webnya: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (sehingga aplikasi akan membuat file baru sebagai: test-www:test-www- ia akan memiliki grup uji-www karena setgid pada direktori!)

Dengan demikian, jika proses aplikasi web menjadi palsu itu hanya akan membaca file tertentu yang akan dibaca grup, dan itu akan dapat menulis ke uploaddir saja. Saya akan sangat menyarankan untuk memiliki uploaddir pada sistem file dengan noexec,nodev,nosuid mountopsi dan memiliki pemantauan konstan untuk file bizzare baru di direktori itu, ditambah juga memonitor setiap proses baru di bawah test-wwwuid.

Di Linux kita bisa menggunakan ACL untuk menyetel izin yang lebih baik. Jika lebih dari satu manusia harus mengunggah data web, akan lebih baik untuk membagi akun manusia dari akun yang digunakan untuk mengunggah file data web, yaitu. untuk membuat akun baru misalnya. test-upload, dan pengguna uji akan mengelola kunci ssh untuk membatasi manusia mana yang dapat ssh / sftp di sana. sshd_configmengetahui ExposeAuthInfoopsi sehingga dapat dikonfigurasi untuk mencatat kunci ssh mana yang digunakan untuk mengunggah data.

Saya sangat meragukan sebagian besar layanan webhosting peduli dengan pemisahan hak, ketika mereka menulis 'aman' tanpa info apa pun yang Anda dapatkan, saya akan mengatakan mereka berbohong.

Jiri B
sumber
php-fpm memungkinkan chrootdan user, groupdiatur untuk kolam. tapi saya tidak akan mempercayai php_admin_value[open_basedir]opsi. Saya juga membaca lebih baik untuk memiliki master PHP-FPM terpisah per pengguna, lihat ma.ttias.be/a-better-way-to-run-php-fpm Untuk membuat instance daemon mudah pada kebanyakan Linux dan distro * BSD.
Jiri B