"Tautan simbolik tidak diizinkan atau target tautan tidak dapat diakses" / Apache pada CentOS 6


30

Saya mendapatkan instalasi CentOS 6 baru, yang memiliki symlink di root dokumen ke file pengembangan saya:

[root@localhost html]# ls -l
total 4
-rwxrwxrwx. 1 root root  0 Sep 18 20:16 index.html
-rwxrwxrwx. 1 root root 17 Sep 18 20:16 index.php
lrwxrwxrwx. 1 root root 24 Sep 18 20:19 refresh-app -> /home/billy/refresh-app/

Httpd.conf saya memiliki ini:

<Directory "/">
    Options All
    AllowOverride None
    Order allow,deny
    Allow from all
</directory>

Target tautan simbolis memiliki izin yang memungkinkan apache membaca apa pun yang diinginkan:

 [root@localhost billy]# ls -l
total 40 (Some entries were omitted because the list was too long
drwxr-xr-x. 7 billy billy 4096 Sep 18 20:03 refresh-app

Saya juga telah mencoba menonaktifkan SELinux dengan mengubah /etc/selinux/conf:

SELINUX=disabled

Namun apa pun yang saya lakukan, ketika seseorang mencoba membuka tautan itu http://localhost/refresh-app/, saya mendapatkan halaman kesalahan 403 DILARANG dan ini ditulis dalam /var/log/httpd/error_log:

Symbolic link not allowed or link target not accessible

Mengapa Apache tidak dapat mengakses target symlink?


Pengguna apa yang menjalankan apache? Bisakah Anda benar-benar membaca sumber daya itu sebagai pengguna itu?
draeath

Selain itu, Anda lebih baik menjalankan selinux dalam mode permisif dan kemudian menggunakan sealert untuk mem-parsing log audit - ini memungkinkan Anda melihat mengapa / bagaimana SELinux menyangkalnya dan seringkali bahkan memberi Anda resolusi.
draeath

@draeath: Saya tidak tahu cara memeriksa itu.
Billy ONeal

@draeath: 1. Ini bukan kotak produksi; Saya tidak peduli jika SELinux tidak aktif. 2. Bagaimanapun, saya hanya pemecahan masalah pada saat ini - saya mungkin akan mengembalikannya setelah saya mengetahui akar masalahnya.
Billy ONeal

Jangan khawatir ini adalah pengawasan umum, pertama kali saya melakukannya saya macet selama berhari-hari, serverfault.com/questions/313485/… :: Ini salah satu dari kesalahan itu. : D
whoami

Jawaban:


44

Menemukan masalah. Ternyata, Apache ingin akses ke bukan hanya direktori saya melayani, /home/billy/refresh-app/tetapi juga setiap direktori di atas itu, yaitu /home/billy/, /home, dan /. (Saya tidak tahu mengapa ... memberi seseorang akses ke subdirektori seharusnya tidak mengharuskan pemberian izin untuk semua yang ada di atas subdirektori itu ....)

Saya kira itu sedang mencari .htaccessatau sesuatu, atau mungkin * nix menjadi aneh tentang bagaimana ia memperlakukan izin untuk transversal direktori.


15
Itu tidak aneh. Begitulah cara kerjanya. Anda harus memiliki + x untuk seluruh jalur yang Anda coba akses.
bahamat

4
@ Bahahamat: Itu tidak masuk akal. Mengapa ada orang yang perlu menjalankan hak istimewa untuk file yang tidak dieksekusi? (Ini benar-benar diskon yang orang tidak harus memberikan hak untuk /... cukup banyak) Sistem dengan ACL biasanya memiliki opsi transversal direktori terpisah. Anda akan berpikir setelah 30 tahun sejak Unix dirancang, dan ketersediaan luas sistem ACL, bahwa ACL akan menjadi standar. : sigh:
Billy ONeal

11
Saya percaya maksudnya + x pada direktori. Cobalah beralih ke pengguna dan melakukan cd ke direktori tanpa / + x. Dari memori + x memungkinkan Anda untuk mengakses tetapi tidak melihat direktori sedangkan + r memungkinkan Anda untuk membuat daftar file dan + w memungkinkan Anda untuk mengubah file dalam direktori tersebut

1
@BillyONeal: frasa "seluruh jalur" menyiratkan direktori.
bahamat

5
Ini adalah perilaku yang benar di unix. Anda perlu menjalankan hak istimewa (+ x untuk g atau o) pada direktori induk yang Anda coba ubah menjadi sub-direktori di bawahnya.
slm

11

Saya memiliki masalah serupa di mana saya memiliki konfigurasi berikut yang digunakan untuk bekerja dengan Ubuntu 10, tetapi berhenti bekerja dengan Ubuntu 14 (Apache 2.4):

<Directory /var/www/vhosts/example.com/httpdocs>
    Options +FollowSymLinks
</Directory>

Beralih ke masalah ini diurutkan (meskipun pengguna server web tidak dapat langsung mengakses symlink)

<Directory /var/www/vhosts/example.com/httpdocs>
    Options +ExecCGI +FollowSymlinks -SymLinksIfOwnerMatch
</Directory>

Dari apa yang saya tahu itu hanya -SymLinksIfOwnerMatchpengaturan dan ada hubungannya dengan perubahan di Apache 2.4 tapi saya belum mencoba meneliti penyebab pastinya.

Saya juga berpikir itu bisa karena openbase_dirpembatasan dalam PHP tapi bukan itu.


6

Kesalahan ini juga dapat disebabkan jika Anda menautkan ke folder terenkripsi.


4

Tampaknya "FollowSymLinks" adalah opsi yang Anda butuhkan di httpd.conf. Ini dijelaskan di sini . Sepertinya Anda mungkin memerlukan aturan di htdocs juga ... tapi itu opsi yang Anda butuhkan.


3
Lihat Options All- FollowSymLinkssudah ditentukan.
Billy ONeal

2

Anda mungkin juga ingin memeriksa apakah selinux diberlakukan atau tidak. Di RedHat / Fedora, jalankan ini:

getenforce

Jika jawabannya 'Menegakkan', Anda mungkin ingin mengeksekusi

setenforce 0

dan coba lagi url di browser Anda.

Perhatikan bahwa saya tidak mengatakan bahwa menonaktifkan selinux adalah cara terbaik untuk menyelesaikan masalah ini, tetapi mungkin membantu untuk mengidentifikasi penyebabnya.


ini memperbaiki masalah sym link tetapi apakah ada efek negatif?
digz6666

2
Options +FollowSymLinks

Buat file .htaccess dengan ini melakukan trik untuk saya (letakkan di dir sebelum symlink).


Dalam kasus saya, saya membuat /var/wwwtautan simbolik ke tautan simbolik menengah lainnya. Jika Anda harus menggunakan tautan simbolis, buatlah tautan simbolis secara LANGSUNG ke tujuan Anda.
Sridhar Sarnobat

0

bahwa apa yang menyelesaikan masalah saya setelah mengizinkan semua izin dan mengizinkan followymlink "Dalam kasus FollowSymLinks secara khusus, HARUS berada di dalam struktur Direktori ketika dalam file .conf. Dari manual Apache saat ini

Opsi FollowSymLinks dan SymLinksIfOwnerMatch hanya berfungsi di bagian atau file .htaccess.

jawab dari sini


0

Solusi saya adalah membuat folder bersama untuk semua repositori yang bernama /home/repo.

Kemudian symlink dari rumah saya sendiri seperti: ln -s /home/repo ~/Code jadi ~/Code/www.xxxx.com/public tunjuk ke /home/repo/www.xxxx.com/public

dan juga tautan ke /var/www/html titik root web apache ke /home/repo/www.xxxx.com/public

Ditemukan di sini: https://github.com/alghanmi/ubuntu-desktop_setup/wiki/Git-Local-Repository-Setup-Guide

Dengan beberapa symlink + grup pengguna akrobat Anda dapat memiliki banyak pengguna / versi yang digunakan.


0

@Billey ONeil @Flion Saya tidak bisa menjawab sejalan (hitung rep rendah)
Inilah yang harus saya lakukan:
( note: alias ll = 'ls $ LS_OPTIONS -lh')

root@Bellach:/var/www/html# ll lego
lrwxrwxrwx 1 root root 43 Sep 10 21:21 lego -> /home/DATA/Documents/Chris/Synced/web/lego/

Sekarang lihat setiap direktori di tautan sumber

root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/Synced/web/
drwxr-xr-x 9 chris chris 4.0K Sep 12  2017 /home/DATA/Documents/Chris/Synced/web/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/Synced/
drwxr-xr-x 20 chris chris 4.0K Mar 27 18:52 /home/DATA/Documents/Chris/Synced/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/Chris/
drwxr-xr-x 36 chris chris 4.0K Jun 17 23:31 /home/DATA/Documents/Chris/
root@Bellach:/var/www/html# ll -d /home/DATA/Documents/
drwxr-xr-x 21 chris chris 4.0K Aug  7 18:22 /home/DATA/Documents/
root@Bellach:/var/www/html# ll -d /home/DATA/
drwxrwxr-- 10 root users 4.0K Sep 10 11:17 /home/DATA/
root@Bellach:/var/www/html# ll -d /home/
drwxr-xr-x 5 root root 4.0K Sep 10 10:37 /home/

/ home / direktori DATA adalah biang keladinya.
Perbaiki dengan ini:

root@Bellach:/var/www/html# chmod +x /home/DATA/
root@Bellach:/var/www/html# ll -d /home/DATA/
drwxrwxr-x 10 root users 4.0K Sep 10 11:17 /home/DATA/

Cara mengatasinya langsung - tidak perlu memulai kembali apache


-1

Anda mungkin juga menyesuaikan pengaturan SELinux Anda, dan setenforce mungkin tidak berada di jalur Anda. Jadi coba ini:

sudo /usr/sbin/setenforce 0

dan untuk membuat ini tetap ada di antara reboot

sudo vi /etc/sysconfig/selinux
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.