Gogs: Repo pribadi dibuat agar dapat dibaca dunia

Saya pikir masuk akal untuk semua repo berada di bawah kendali Gogs, tapi mungkin masuk akal untuk mengekspos pengaturan UMAS untuk mereka?

Saya pikir semua direktori (termasuk gogs-repositories/ sendiri) harus memiliki filemode 750 pada disk, terlepas dari visibilitasnya. (Karena Anda dapat memiliki repositori publik tetapi REQUIRE_SIGNIN_VIEW diaktifkan). Sebagai perbandingan, gitolite memberlakukan filemode 700.

Mungkin itu bisa berupa konfigurasi seluruh sistem: izin untuk repo pribadi, izin untuk repo publik.

Semakin saya memikirkan masalah ini, semakin saya yakin bahwa Gogs sendiri harus membuat beberapa perubahan izin pada sistem file untuk beralih antara konfigurasi pribadi dan publik untuk repositori. Saya tidak dapat memikirkan cara lain untuk memberikan manajemen penuh kepada Gogs atas repositori.

Saya mengerti alasan tentang mode REQUIRE_SIGNIN_VIEW , tetapi jika saya dapat mengonfigurasi izin untuk repo pribadi dan publik, saya juga dapat membuat keduanya tidak dapat dibaca dunia saat mengaktifkan pengaturan itu (dan tanda centang dapat memperingatkan saya jika saya tidak' lakukan itu).

Ketika saya akhirnya memutuskan untuk menambahkan pengaturan umask di skrip pemula, apakah Anda tertarik dengan PR untuk itu? (tapi saya hanya menyentuh skrip init debian, bukan yang lain).

Untuk systemd, menempatkan direktif UMask= dalam file unit sudah cukup.
Tapi umasking seluruh proses tentu bukan solusi yang paling elegan.

Saya masih ingin melihat komentar pengembang tentang masalah ini @Unknwon

Saya pikir ini agak di luar tugas Gog. Jika seseorang memiliki akses ke server, pribadi/publik dari Gogs tidak berguna. Semua file dikelola oleh perintah git , Gogs tidak CRUD file mentah tersebut.

Karena gogs membuat repositori, gogs dan hanya tugas gogs untuk mengatur izin file yang tepat pada mereka.

Jika seseorang memiliki akses ke server, privat/publik dari Gogs tidak berguna

Itulah yang coba diatasi oleh masalah ini! Saat ini memang sangat benar. Karena repositori dapat dibaca dunia, setiap pengguna yang memiliki akses ke server juga dapat mengakses setiap repositori, bahkan repositori pribadi. Saya pikir kita semua setuju bahwa itu tidak cukup optimal. Tetapi ada solusi untuk masalah yang sangat khusus ini, ditemukan beberapa tahun yang lalu: Izin file! Dengan tidak membuat file dapat dibaca dunia, hanya pengguna yang diizinkan (yaitu pengguna dalam grup "git") yang dapat mengakses file.

Semua file dikelola oleh perintah git, Gogs tidak CRUD file mentah tersebut.

Tidak benar-benar mengubah apa pun. git tidak mengelola apa pun sendiri, Gogs masih merupakan aplikasi yang memutuskan apa yang harus dilakukan dengan file, tidak masalah _bagaimana_ itu memodifikasi atau membacanya. Mengapa git berurusan dengan izin file? Merupakan tanggung jawab penelepon untuk memiliki hak pengguna yang tepat dan menetapkan umask.

Itulah yang coba diatasi oleh masalah ini! Saat ini memang sangat benar. Karena repositori dapat dibaca dunia, setiap pengguna yang memiliki akses ke server juga dapat mengakses setiap repositori, bahkan repositori pribadi. Saya pikir kita semua setuju bahwa itu tidak cukup optimal. Tetapi ada solusi untuk masalah yang sangat khusus ini, ditemukan beberapa tahun yang lalu: Izin file! Dengan tidak membuat file dapat dibaca dunia, hanya pengguna yang diizinkan (yaitu pengguna dalam grup "git") yang dapat mengakses file.

Saya lebih percaya itu adalah masalah Anda menjalankan Gogs di bawah pengguna yang tepat.

Tidak benar-benar mengubah apa pun. git tidak mengelola apa pun sendiri, Gogs masih merupakan aplikasi yang memutuskan apa yang harus dilakukan dengan file, tidak peduli bagaimana ia memodifikasi atau membacanya. Mengapa git berurusan dengan izin file? Merupakan tanggung jawab penelepon untuk memiliki hak pengguna yang tepat dan menetapkan umask.

Siapa yang membuat file yang mengelola izin file, dan itu adalah git .

@Unknwon menurut saya dari komentar Anda di sini dan #2943 dan #2940
bahwa Anda tidak menghargai integrasi Gogs dengan alat lain,
melainkan melihat Yajuj sebagai satu-satunya aktor dalam sistem.

Pendekatan ini membatasi kasus penggunaan untuk Gogs.

Sebagai perbandingan, lihat bagaimana gitolite menangani integrasi:
http://gitolite.com/gitolite/gitolite.html#gitweb -daemon

@Unknwon menurut saya dari komentar Anda di sini dan #2943 dan #2940
bahwa Anda tidak menghargai integrasi Gogs dengan alat lain,
melainkan melihat Yajuj sebagai satu-satunya aktor dalam sistem.

Pendekatan ini membatasi kasus penggunaan untuk Gogs.

Sebagai perbandingan, lihat bagaimana gitolite menangani integrasi:
http://gitolite.com/gitolite/gitolite.html#gitweb -daemon

Sepertinya tidak relevan dengan utas ini.

Saya lebih percaya itu adalah masalah Anda menjalankan Gogs di bawah pengguna yang tepat.

Saya tidak berpikir Anda memahami masalah ini. Tidak masalah apa pengguna gogs berjalan, karena gogs memberikan repositori mode file 755. Digit ketiga menunjukkan izin untuk semua pengguna selain pengguna pemilik dan grup . A 5 berarti baca (4) + eksekusi (1) (yang sebenarnya adalah daftar file dalam kasus direktori), artinya semua pengguna di sistem dapat membaca repositori.
Ini adalah masalah, karena kemungkinan besar Anda tidak ingin semua pengguna (termasuk semua layanan yang berjalan!) di server dapat membaca repositori.

Siapa yang membuat file yang mengelola izin file, dan itu adalah git.

Tidak, bukan begitu cara kerjanya. Bagaimana seharusnya utilitas baris perintah git mengetahui sendiri apa yang seharusnya dapat dibaca oleh pengguna?
Git membuat file repositori menggunakan umask yang baru saja disetel. Masalahnya adalah gogs tidak menyetel umask , jadi umask default 022 digunakan, yang mengarah ke repositori yang dibuat dengan filemode 755.

Hanya chmod 0770 direktori induk tempat repositori berada dan semuanya bahagia. Bukankah pekerjaan gogs mengelola izin sistem file, yang harus dilakukan oleh administrator server

Administrator server hanya dapat mengatur izin pada file yang
ada pada satu waktu, tetapi karena Gogs _membuat_ file baru
dan direktori, itu harus bertindak secara bertanggung jawab dan mengatur izin
dengan tepat.

Yang mengatakan, ya, mengatur izin direktori induk mungkin berhasil
dalam kebanyakan kasus penggunaan (0750, untuk kasus saya).

@Marco01809

Saya tidak berpikir Anda memahami masalah ini. Tidak masalah apa yang dijalankan oleh gogs pengguna, karena gogs memberikan repositori mode file 755.

@strk

tetapi karena Gogs _membuat_ file baru
dan direktori, itu harus bertindak secara bertanggung jawab dan mengatur izin
dengan tepat.

Dikatakan berkali-kali, bukan Gogs, baris perintah git .

Hanya chmod 0770 direktori induk tempat repositori berada dan semuanya bahagia.

Saya setuju ini solusi yang bagus.

Bukankah pekerjaan gogs mengelola izin sistem file, yang harus dilakukan oleh administrator server

Administrator server tentu harus menjaga aspek keamanan seperti itu, tetapi daemon harus memiliki default yang aman dan tidak membahayakan data pribadi yang tidak perlu.

Dikatakan berkali-kali, bukan Gogs, baris perintah git.

Oke, jadi apa yang Anda tidak mengerti?? Saya sudah menjelaskan bahwa Anda sebenarnya harus memberi tahu git bahwa itu harus membuat file dengan mode file tertentu dengan mengatur umask. Git tidak mengatur mode file sendiri secara acak.

Aa dan Anda (sebagai sysop) harus memberitahu gogs untuk memiliki umask, dengan mengkonfigurasi
file layanan Anda...

Itu akan berhasil juga, tetapi praktik yang agak jarang. Dan tetap saja, gogs harus mengaturnya di luar kotak. Seperti sekarang, dengan instalasi gogs standar, satu masalah keamanan di layanan apa pun yang berjalan di server bisa cukup untuk membuat semua repositori pribadi Anda dicuri.

@Marco01809

Oke, jadi apa yang Anda tidak mengerti?? Saya sudah menjelaskan bahwa Anda sebenarnya harus memberi tahu git bahwa itu harus membuat file dengan mode file tertentu dengan mengatur umask. Git tidak mengatur mode file sendiri secara acak.

Apa yang tidak kamu mengerti? Beri tahu saya cara mengatur umask ketika Anda melakukan git init ?

Yah, saya belum pernah memprogram di Go sebelumnya, tetapi mari kita lihat apakah saya dapat membantu Anda dalam hal ini.

Ternyata ada dokumentasi yang menentukan cara melakukan syscalls dari Go.
https://golang.org/pkg/syscall/#Umask
Tentu, tidak menyatakan apa pun tentang cara kerja umask(), jadi mari kita lihat halaman manualnya, ya?
http://man7.org/linux/man-pages/man2/umask.2.html

umask() menyetel topeng pembuatan mode file proses panggilan

Penekanan khusus harus diberikan pada:

Proses anak [...] mewarisi umask induknya.

Jadi Anda benar-benar _sebut saja_ sebelum Anda memulai proses git. Sama seperti dulu di semua platform yang sesuai dengan POSIX dalam 15 tahun terakhir. Di C Anda akan melakukan:

umask(0027);
system("git init");

Sial, kamu bahkan bisa melakukan sesuatu seperti
system("sh -c 'umask 027; git init'")
(Meskipun tidak sebaik itu.)

Tapi tunggu, masih ada lagi!
Pengembang git pasti telah memperhatikan betapa tidak nyamannya mengatur umask secara manual. Mereka memperkenalkan cara yang lebih sederhana untuk menentukan mode file mana yang akan digunakan: Argumen --shared=0xxx. Menurut dokumentasi git yang ditemukan di https://git-scm.com/docs/git-init :

--shared[=(false|true|umask|group|all|world|everybody|0xxx)]
0xxx
    0xxx is an octal number and each file will have mode 0xxx. 0xxx will override users' umask(2) value.

Perhatikan bahwa --shared memiliki beberapa efek samping, jadi pengaturan umask lebih disukai.

Tolong beri tahu saya kapan saja jika saya dapat membantu Anda membaca dokumentasi lainnya.

Apa yang membuat saya bertanya-tanya, bagaimanapun, Anda adalah pengembang utama layanan _self-hosted_ git namun tampaknya tidak tahu apa-apa tentang hal ini dan menganggap izin file "agak di luar tugas gogs". Memberi Anda firasat buruk tentang keamanan gogs secara umum.

Jadi Anda _secara harfiah hanya memanggil_ sebelum Anda memulai proses git.

Seperti yang harus dilakukan oleh file layanan Anda (init.d, sysvinit, systemd, dll) jika Anda menginginkannya :wink:

Meskipun saya setuju bahwa install-docs dapat/harus menyebutkan ini di suatu tempat ...

@Marco01809 Izin file selalu berada di luar cakupan layanan apa pun, karena sistem init (systemd, dll) harus mengatur umask bila perlu. (kecuali layanan tersebut adalah sistem init :laughing: )

Saya masih merasa berguna bagi Gogs untuk dapat _mengubah_
sesuatu tentang repositori saat beralih di antara
publik dan swasta, di samping penciptaan awal.

Itu bukan sesuatu yang bisa dilakukan umask sendiri.

Seperti yang harus dilakukan oleh file layanan Anda (init.d, sysvinit, systemd, dll) jika Anda menginginkannya

Interwebs menyatakan daemon harus secara eksplisit mengabaikan umask yang disetel dari luar.

Tujuan umask adalah untuk memungkinkan pengguna memengaruhi izin yang diberikan ke file dan direktori yang baru dibuat. Daemon tidak boleh membiarkan dirinya terpengaruh oleh pengaturan ini , karena apa yang sesuai untuk pengguna belum tentu cocok untuk daemon.

Dalam beberapa kasus, mungkin lebih nyaman jika umask disetel ke nilai bukan nol. Ini sama-sama dapat diterima: poin pentingnya adalah bahwa daemon telah mengambil kendali nilai, bukan hanya menerima apa yang diberikan .

Diambil dari http://www.microhowto.info/howto/cause_a_process_to_become_a_daemon.html#idp34384

Jadi, satu-satunya sumber yang tepat untuk bagaimana layanan terkenal/digunakan (apache, php-fpm, nginx, mysql, postgres) menetapkan umask adalah MySQL yang melakukannya dengan operasi bitwise alih-alih menggunakan umask() .
_Semua_ yang lain merekomendasikan menggunakan init-system untuk pengaturan umask :unamused:

Ya, MySQL membaca variabel lingkungan UMASK (Perhatikan fallback ke mode file aman 640 jika tidak ada!), Kemudian meneruskannya ke panggilan open() alih-alih menggunakan umask() sebelumnya (open akan membuat file saat Parameter O_CREAT diberikan).

nginx menangani izin file itu sendiri juga, tanpa bergantung pada variabel eksternal sama sekali.
Saat startup bahkan menimpa umask yang disetel oleh pengguna (atau dengan skrip init, mungkin).
nginx hanya menulis file dan log sementara, keduanya ditangani dengan baik: Lihat this dan this dan this .

php-fpm tidak mengelola data pengguna itu sendiri (yang akan diserahkan ke aplikasi php yang sebenarnya), kecuali log lagi dan file sesi, yang menggunakan fungsi ini . Keduanya menyatakan filemode secara eksplisit.

Saya belum memeriksa postgres dan Apache.

Karena kita berbicara tentang subproses di sini, kita tidak dapat secara langsung menentukan apa yang akan diteruskan ke panggilan open(). Tetapi dengan menggunakan umask kita dapat menutupi mode yang diteruskan ke open(), jadi inilah yang kita butuhkan.

Menyetel umask di file init mungkin baik-baik saja bagi pengguna yang mencoba mencapai sesuatu yang tidak mungkin dilakukan, tetapi itu bukan sesuatu yang harus diandalkan oleh daemon untuk penanganan izin file yang tepat.
Saya tidak sepenuhnya menentang untuk menentukan umask di file init tetapi ada beberapa kelemahan:

• Bagaimana jika pengguna atau distribusi menggulung skrip init mereka sendiri? (seperti yang dilakukan packager.io)
• Bagaimana dengan instalasi gog yang sudah ada? (chmod juga diperlukan)
• Itu tidak akan memenuhi permintaan OP (memiliki izin berbeda untuk repo publik/pribadi)
• Dengan menggunakan umask di file init, kita tidak hanya meng-umask subproses git, tetapi seluruh proses gogs. Bagaimana jika gogs pada suatu saat harus membuat file tertentu agar dapat dibaca oleh dunia? Itu harus menggunakan umask() kemudian, hanya sebaliknya (kali ini memperluas izin)

Oke, saya yakin. umask(0027) baik-baik saja? atau harus setting? pengaturan yang berbeda pada publik/pribadi akan berakhir dengan hit kinerja (hampir tidak terlihat tetapi tetap ...), dan sulit untuk dikelola, jadi saya kurang lebih menentangnya kecuali seseorang memiliki argumen yang valid mengapa itu diperlukan: mengedip:

Anda benar-benar ingin menduplikasi manajemen izin sistem file di sisi gogs? Semoga berhasil dengan itu, terutama pada Windows NTFS :) (Pemilik, pewarisan izin ... ). Berkali-kali dikatakan - bukan pekerjaan gogs untuk menduplikasi peran administrator. jika sysop perusahaan Anda tidak dapat menghadapinya, tembak atau tembak dia, tergantung hukum setempat :)

umask(0027) baik-baik saja? atau harus setting?

Saya percaya 0027 pada akhirnya akan menjadi pilihan standar.
Misalnya ketika gogs dijalankan sebagai pengguna "git":

• gogs akan dapat membaca+menulis file
• jika Anda ingin layanan/pengguna lain di sistem dapat membaca dan mendaftar (tetapi tidak menulis) repositori, Anda cukup menambahkannya ke dalam grup "git"
• semua pengguna lain tidak dapat membaca, menulis, atau membuat daftar repositori yang dikelola oleh gogs

Semoga berhasil dengan itu, terutama pada Windows NTFS :) (Pemilik, pewarisan izin ... )

Masalah ini terutama tentang izin file pada sistem yang kompatibel dengan unix dan sejujurnya saya tidak tahu apa-apa tentang izin di windows. Windows sangat berbeda pula.

Berkali-kali dikatakan - bukan pekerjaan gogs untuk menduplikasi peran administrator.

Daemon yang menangani izin file mereka adalah standar yang ditetapkan. Hanya untuk memastikan saya juga memeriksa postgres (menggunakan umask 077 saat membuat database baru -> filemode 600). Semua layanan terkenal melakukannya, jadi harap buat cadangan klaim Anda yang bertentangan.

Setiap OS terkenal sudah memiliki segalanya untuk mengelola akses pengguna ke file dan direktori.
Di Unix:
chown gogs_user:trusted_gogs_users /srv/gogs; chmod 0700|0750|0770|0755 /srv/gogs/repos; umask 00xx; su -c "gogs web -c /etc/gogs/app.ini" gogs
dan Anda selesai.
Setiap manajemen izin sistem file sisi daemon akan menjadi:

1. Tidak portabel.
2. Lambat.
3. Rawan kesalahan.
4. Duplikat konyol fungsi OS
5. Tidak berurusan dengan SELinux, Apparrmor, GRsecurity, NTFS ...

Tentang portabilitas:
panggilan sistem umask sesuai dengan SVr4, 4.3BSD, POSIX.1-2001.

umask 00xx; su -c "gogs web -c /etc/gogs/app.ini" gogs

Seperti yang dijelaskan dalam cara yang saya tautkan sedikit di atas, daemon harus secara eksplisit menolak umask yang ditetapkan sebelumnya dan menanganinya sendiri.

1 Tidak portabel.

Hanya berlaku untuk windows. Namun, semua layanan terkenal menerapkan penanganan izin file meskipun mereka juga menargetkan windows.

2 Lambat.
3 Rawan kesalahan.

???

4 Konyol menduplikasi fungsionalitas OS

Sebenarnya, perintah yang disediakan oleh OS hanyalah cara mudah untuk memanggil syscalls ini dari shell.

5 Tidak berurusan dengan SELinux, Apparrmor, GRsecurity, NTFS ...

Yang terakhir ini hanya nomor 1 lagi. Apa hubungannya dengan tiga lainnya? Kami tidak perlu menggunakannya untuk memiliki izin file yang tepat dan memiliki izin file tidak mencegah siapa pun untuk menggunakannya. Mereka adalah topik yang sama sekali berbeda.

Sekali lagi, harap dukung klaim Anda bahwa daemon seharusnya tidak menangani izin file secara tepat dengan menyediakan materi untuk dibaca.

Silakan, baca semua referensi Anda sendiri, dan bukan hanya bagian yang Anda suka

Ada satu alasan sederhana untuk menjauh dari daemon yang mengatur izinnya sendiri - kerumitan yang tidak perlu.

1. Tidak berurusan dengan SELinux, Apparrmor, GRsecurity, NTFS ...

Itu dapat menyebabkan banyak komplikasi dalam kode untuk memasukkan pengecualian untuk contoh yang disebutkan dan saya yakin sebagian besar orang akan setuju untuk membuatnya tetap sederhana.

Kedua, saya pikir di sebagian besar Gogs menggunakan sistem lokal, pengguna tidak boleh mengakses repo sehingga perubahan izin sederhana untuk direktori induk lebih dari cukup untuk menyelesaikan masalah keamanan seperti itu. Jika karena alasan Anda ingin mengizinkan pengguna lokal mengakses repo tertentu, solusi seperti menggunakan symlink dapat diterapkan, tetapi seperti yang ditunjukkan @edacval , hingga admin.

Sebuah symlink tidak dapat menghindari izin direktori

@strk benar, saya buruk. Mungkin ACL atau bind mount adalah contoh yang lebih tepat.

Saya tidak pro pada izin file, tetapi saya menganggap izin direktori anak apa pun mengikuti izin orang tua mereka?

Asumsi yang salah.
Izin pada direktori anak tidak tergantung pada izin orang tua
yang, dengan pengecualian bit "eksekusi", yang mencegah
turun ke anak-anak dari orang tua, sehingga Anda tidak dapat mencapai apapun
anak dari direktori tempat Anda tidak memiliki izin eksekusi.

Catatan Anda masih dapat menjangkau file yang merupakan anak dari direktori Anda
tidak memiliki izin eksekusi pada IFF, file-file ini dapat dijangkau dari
jalur lain (yang dapat dieksekusi) melalui tautan keras.

Asumsi yang salah.
Izin pada direktori anak tidak tergantung pada izin orang tua
yang, dengan pengecualian bit "eksekusi", yang mencegah
turun ke anak-anak dari orang tua, sehingga Anda tidak dapat mencapai apapun
anak dari direktori tempat Anda tidak memiliki izin eksekusi.

Jika itu masalahnya, saya masih tidak berpikir itu tugas Gogs untuk mengatur setiap bit.

umask terdengar bagus tetapi tidak terlalu kompatibel.

umask sangat kompatibel, karena distandarisasi dalam spesifikasi POSIX (Linux, OpenBSD, FreeBSD dan Darwin/OS X mengimplementasikannya). umask didukung pada 100% sistem yang menggunakan mode file unix.

Adalah tugas Gogs untuk melindungi data yang didapatnya. Jadi mengatur izin minimal secara default adalah cara yang harus dilakukan.